When I first read the recent article from CISA titled “Tackling the National Gap in Software Understanding,” I had the same reaction I imagine many of you did: Well, of course this is necessary. Who in their right mind doesn’t want better visibility into the software used in our most mission-critical systems?
But then I thought a bit more. It’s not just necessary—it’s overdue. And not only for national security systems. This gap in software understanding exists across nearly every enterprise and agency in the public and private sector. The real challenge is not recognizing the problem. It’s addressing it early, systemically and sustainably—especially in a DevSecOps context.
Let’s dig into what this really means, why it matters, and where we go from here.
The Software Visibility Gap is a National Risk
The CISA article—and the reports it references from MITRE, NSA, ONCD, and others—highlights a fundamental issue: We don’t know enough about the software running inside our critical infrastructure. We lack the ability to fully understand what’s in our software, how it’s built, and where the risks lie.
This isn’t a new problem. But with the rise of supply chain attacks, component vulnerabilities and ever-expanding software dependencies, the risk is no longer theoretical. It’s existential.
Here’s the kicker: You can’t secure what you don’t understand. You can’t defend what you can’t see.
So yes, we need to close the gap in software understanding—urgently. But the gap isn’t just about national security. It’s a DevSecOps problem at its core.
DevSecOps: Where the Gap Can Actually Be Closed
The big idea in DevSecOps has always been this: shift security left, embed it early and often, and make it everyone’s responsibility.
This makes DevSecOps the perfect context for addressing the software understanding gap. Why? Because the best time to capture visibility into your software’s inner workings isn’t after it’s shipped—it’s while it’s being built.
SBOMs and Supply Chain Security Are Just the Start
Software Bill of Materials (SBOMs) are getting a lot of attention—and rightly so. They provide a machine-readable inventory of every component in a piece of software, down to the library level. SBOMs are a baseline requirement for software visibility, but they’re not the whole story.
What we need is end-to-end traceability—from code to artifact to runtime. That includes:
- Component provenance: Where did this library come from, and who maintains it?
- Build pipelines: What tools and environments were used to compile the software?
- Deployment metadata: When and where was this version deployed, and under what conditions?
This kind of visibility is what lets you “understand” software in the true sense—not just scan it for CVEs.
And the only way to build this visibility in without slowing everything down is to integrate it directly into DevSecOps workflows.
The Role of Policy—and the Promise of Collaboration
I’ll give credit where credit is due: CISA and its federal partners are thinking bigger. They’re not trying to do this in a silo. They’re bringing in multiple agencies—ONCD, NSA, and others—and they’re inviting the cybersecurity and open source communities to the table.
That’s a smart move. Because this isn’t a compliance exercise. It’s a transformation effort.
Too often, the conversation around software security gets stuck on source code access. But as anyone in DevSecOps knows, access to source code alone doesn’t solve the visibility problem. You need insight into artifacts, pipelines, environment variables, configurations, and more. We’re talking about a whole-of-lifecycle approach—not a repo review.
The fact that this is now a coordinated, multi-agency initiative is encouraging. If done right, it could set the standard not only for how the federal government secures software, but how the private sector does too.
Will We See It Through?
And yet… I’ve been around long enough to know how these things go. Big announcement, slick webpage, maybe even a press conference. And then?
Crickets.
We’ve seen this script before. Promising initiatives that fizzle out after leadership changes, priorities shift, or budgets get squeezed. Federal agencies—CISA included—have a revolving door problem. Continuity is hard when your champions keep leaving. You need people who aren’t afraid to speak the truth and do what is right.
So here’s the real question: Will we stick with it? Will the teams behind this initiative have the mandate—and the stamina—to drive this effort forward once the spotlight dims?
Because make no mistake: closing the software understanding gap is not a one-and-done project. It’s a multi-year slog. It requires rewriting procurement policies, updating build systems, retraining teams, and investing in open standards. It’s not glamorous, but it’s vital.
Why It Matters—For DevSecOps and Beyond
If we do see it through, this won’t just be a win for federal cybersecurity. It’ll be a win for the DevSecOps movement.
It will reinforce the idea that visibility, traceability, and accountability are not add-ons—they’re first principles. It will accelerate the adoption of SBOMs, secure build pipelines, artifact attestation, and zero trust architectures.
Most importantly, it will help us build software we can trust. And in today’s world, that’s not just a technical achievement. It’s a national imperative.
Let’s hope we have the will to match the ambition.