Introduction: Security and Innovation in Aerospace & Defense
Hello, everybody, and welcome to this SPK and Associates vlog. My name is Michael Roberts, and I’m the Vice President of Sales and Marketing here at SPK.
Today, we’re going to talk about the tug-of-war between security and innovation.
When people think about cybersecurity in aerospace and defense, they think about protecting networks or preventing cyberattacks. But increasingly, the software development environment itself has become one of the most important assets to secure.
Now, the good news is security and innovation don’t have to compete with one another in this area. In fact, when engineering organizations build the right secure development platform, they often discover that they can improve collaboration, increase developer productivity, and accelerate delivery, all while still strengthening that security and governance approach.
So, joining me today is someone with firsthand experience in navigating these types of challenges. I’m excited to welcome Lemuel Valdez.
Lemuel, please introduce yourself.
Meet Lemuel Valdez
Thanks, Michael. It’s actually a pleasure being here.
So, who am I? I’m LemuelValdez. I’m the Chief Information Security Officer here at Common Sackcom, where I lead cybersecurity, product security, governance, risk, pretty much, you name it, secure engineering across a global organization.
What we do is develop satellites and GLO satellites and mission-critical communications technologies for commercial, maritime, government, and public sector customers.
So, why me?
My background really spans secure software development, product security, supply chain, and implementing and looking at international regulatory frameworks, which includes CMC, NIST, NIST 2, ISO, IE643 443, and other military-critical infrastructure-related frameworks that you get to see.
So, we get to talk to somebody that really has to do this in the real world today. This is going to be an interesting conversation.
What Does a Secure Software Development Environment Really Mean?
So, for organizations that are developing these mission-critical communication technologies, what does a secure software development environment really mean? And why is it so important to protect both the intellectual property and to build that customer trust?
Really, it depends on how you look at it and what your definition of a secure development environment really means, right?
So, for mission-critical communications, a secure software development environment is not just a locked-down laptop and a firewall. It is an engineered socio-technical system where people, processes, and platforms are really designed to prevent compromise from ever propagating into deployed code.
I think, at times, we spend time asking the wrong question. Instead of looking at it from, “How do we secure software development?” we have to put that engineering-first approach forward.
The better question, in my mind, has always been: How do we get the engineers to trust every single line of code, but also ensure it’s applicable to how they develop?
For us as an organization, software simply isn’t an application anymore. It’s part of an operational capability.
Looking at it this way, a vulnerability isn’t just a bug. It can become an intelligence collection opportunity, a supply chain risk attack, or even a mission failure.
So, a modern secure development environment isn’t just about your Git. It isn’t about your CI/CD environment or even your code scans.
It’s basically about when an artifact, or the environment itself, from requirements, source collection, dependencies, and the like, is authenticated, traceable, and verified.
That’s really what, for me, is important: the practicality of it.
There has to be some sort of isolation, but also encouragement that people can develop safely and securely while being minimally hindered, but still having the assurance behind what is being developed.
That is really important for things that we develop as a mission-critical communications environment.
A compromised build pipeline can become an on-ramp for adversaries into operational networks, and an exfiltrated repo can leak classified design patterns, implementation, or spectrum management logic that is effectively our own crown jewel.
For me, it means that we have to secure identities, least privileges, reproducible builds, and the like.
But the objective really isn’t simply to stop hackers. We need to provide confidence that the software we deploy today is exactly the software engineers are intending to build.
Increasingly, customers that we do have, particularly governments, the public sector, and the like, aren’t buying just software. What they’re buying is assurance, and trust is becoming a more competitive differentiator in this market.
Building Security Around the Way Engineers Work
I love that.
Probably a couple of things that I’m going to pick out of what you said that I liked.
It is the way that engineers work, right? It’s not just, “Well, here’s some software, and go build software on top of it.”
It has to match the way that they work.
You mentioned the social component too, the process component. They have to feel like this is part of the way that they’re working to be able to get an outcome and a capability.
Really important.
Modernization and Supporting CMMC Requirements
So, moving to the next component here, and I realize that especially to do something like this is going to require modernization and using more modern frameworks and more modern infrastructure and whatnot.
Every modernization effort has hurdles. We’ve all been through it at some point.
So, what are the biggest technical or organizational challenges that teams face when they’re building a platform that’s capable of supporting something like CMMC 2 requirements?
What most people always think about is that they have to look at it from what you already have.
Most organizations think of frameworks such as CMMC as solely a security problem. It isn’t.
The biggest challenge isn’t really CMMC itself. It’s the organizational complexity and how to deal with it.
Many companies have world-class engineers working on systems that were never designed to work together.
But if you look at how developers actually work, developers use one single platform, security another, operations another, and compliance another platform on top of all of this.
Then you have all the executives looking at nine or ten different dashboards showing different truths, where the reality of the matter is that the next generation of engineering platforms needs to break those silos.
Without breaking those silos, we are unable to implement frameworks completely, pragmatically, and holistically.
Rather than having security generate a report after engineering finishes, and engineering generate another report that creates an assurance of software, it needs to become more transformational.
In my personal opinion, that’s both using AI but also ensuring that communication is done at the level where it should be.
You are unable to implement frameworks such as CMMC or ISO without breaking that mold that you already have.
The difficult part is changing that decades-long engineering culture, but also changing how we operate.
Breaking Down Tool and Organizational Silos
What is most important is to look at the tools that you have.
Organizations have always accumulated dozens of disconnected tools.
The reality is, what everyone’s been preaching from a vendor side and others is that those disconnected tools can actually be integrated together to form one single enhanced monitoring platform.
Instead of actually having separate identity platforms, separate scanners, manual spreadsheets, and email approvals, they don’t scale.
And spreadsheets don’t scale.
That’s right. That’s right.
They don’t.
This is why we started looking at it from, “Okay, what are the engineers actually using?”
They’re using Jira.
Okay, we have our own ticketing system in it. Why don’t we just merge things together and actually work together in one single platform?
Because it gives more visibility. Engineers don’t actually know what’s happening within an environment.
The organizations that are actually succeeding are building developer platforms, not security platforms.
Developers shouldn’t really need to understand every control family within CMMC or ISO or anything else like that. But the platform itself should make secure behavior the easiest behavior.
Evidence by Design and Continuous Compliance
Another challenge is just evidencing, right?
Security folks alike should not spend time evidencing on a daily, weekly, or monthly basis. Let the platform do the evidencing for you.
We need to move away from the mindset that we need to prepare for an audit six months in advance.
Modern organizations should expect to generate evidence continuously.
Every pipeline execution, approval, deployment, code review, everything needs to become evidence by design.
That’s where engineering maturity actually meets compliance maturity: having a platform that does the work for you.
Where AI Fits Into Secure Engineering
Now, what I’m getting asked at times is: Where does AI fit into this?
AI becomes transformational.
Instead of analysts collecting evidence, you can have AI help look at it from an engineering activity perspective.
It helps you map it to regulatory requirements so that engineers don’t have to know control XYZ means XYZ or BYDX, right?
It helps them look at how it should be generated, how it should look, and how it’s supposed to be applied in the environment.
They don’t need to know exactly how it really should be. AI can do that.
I love your point about what you said: the easiest path should be the path that the platform allows the engineer to proceed in, which should be the auditable, easily traceable path.
Yeah.
Advice for Organizations Beginning Their Secure Development Journey
Okay. Last question here.
So, if another engineering organization is just at the beginning of this whole journey toward building that secure software development platform, what’s one piece of advice that you’d give them to help avoid some common mistakes and some of the things you’ve talked about today?
I would have to give advice about buying tools.
Instead of buying tools first, the most valuable move is to treat your secure engineering platform as a product with a roadmap, stakeholders, and a clear value proposition.
Practical and non-obvious advice for me has always been: start with a thin slice.
Pick one representative product line or program and build a secure pipeline end-to-end, from code commits to signed artifacts, and use it as a reference implementation.
Don’t just say to them, “I’m going to build it out for everything.”
It doesn’t work, right?
Co-Design With Developers and Compliance
Co-design with your developers and compliance.
Adopt an engineering-first mindset.
Put engineering, security, and compliance in the same room and define what “secure enough to ship” actually really means.
Then we need to encode those criteria as pipeline gates instead of Word documents that engineers are never going to read.
Okay?
Because they won’t.
Begin to ask yourself: How should software move from an idea to production?
Build it into those stages that maybe they already have.
Engineers may not be in security, but they know how to code. They know how to check if their code is going to work. They know quality gates.
It might have a different word in security, but that’s what they already have.
You can embed it into what they already have.
Design Around People, Not Controls
Too many organizations, for me, look at it from a tools perspective before actually understanding the developer workflows.
That’s one of the things that’s really backwards.
The best secure development platforms I’ve seen are designed around people, not controls.
And this is really one thing: you won’t reach the dreams of zero trust and CMMC overnight.
You won’t achieve software supply chain integrity overnight.
You treat it like continuous engineering improvement.
Even in our organization, we still do.
We don’t have a perfect platform where we just sleep and that’s it.
We have people within this organization whose job is to improve the platform and modernize it and ensure it is fit for purpose for now, but also for the future.
Celebrate Small Wins and Continuous Improvement
But what’s really important, and what I’ve seen, is culture.
Celebrate the small wins.
Aim from a continuous risk reduction perspective, but celebrate the little tiny things that you’ve actually achieved.
It doesn’t just improve culture, but it actually creates that mindset of improvement and makes the engineering-first approach better.
Michael’s Takeaway From Lemuel’s Advice
Lemuel, thanks for your guidance and insight there.
Having somebody who’s been through this is really important to share with others because, now knowing your journey, I can definitely say that is the best advice that you can give to somebody else trying to do something similar.
So, thank you for your time today. Really appreciate it.
Key Takeaway: Secure Development Is More Than Compliance
One of the biggest takeaways, I think, from this discussion in creating that secure software development environment is that it isn’t about just checking compliance boxes or passing audits.
It’s about creating an engineering environment where developers can build innovative products with confidence, understanding the culture, the processes, and the tools that are involved, and hopefully generate some really cool code with great intellectual property that is protected during that entire software development life cycle.
As organizations continue adopting these AI-assisted environments, modern DevSecOps practices and all the things around that are increasingly concerned about being secure and having a secure, scalable, and compliant development environment.
It’s not about just reducing risk.
It’s really about building that environment that allows you to go faster, innovate better, and maintain that competitive advantage.
Closing
So, if your organization is evaluating how to modernize its software development platform, strengthen compliance efforts, or improve developer productivity while maintaining all the security, we have a team here at SPK and Associates that can help with that.
So again, thanks to Lemuel, and thanks for watching.
We’ll see you next time on another SPK and Associates vlog.
