Compliance Is Getting Real
Why software integrity is becoming the defining security challenge of the next decade
Tim Miller
January 27, 2026
I’ve spent a lot of my career inside organizations where the stakes were high and the margin for error was thin.
At Bridgewater, MUFG, and Citi, my teams were under constant pressure to deliver. Faster releases. More automation. Less friction. And inevitably, the same refrain: “Now pause — security needs to sign off.”
Those teams weren’t reckless. They wanted to build securely. We used the tools. We followed the processes. We added scanners, gates, and approvals. But what we never had was clarity.
Security noise drowned out the signal. Compliance became a last-minute hurdle instead of an integrated discipline. And when something went wrong, proving what happened — and whether we were truly in control — was harder than anyone wanted to admit.
That experience is why I believe we’re at an inflection point today. And why, in 2026, organizations that still treat it as a checkbox exercise are going to feel real pain.
The shift no one can ignore anymore
Across industries, regulators, customers, and auditors are asking a new class of questions:
- What exactly is inside your software?
- Where did it come from?
- How do you know it hasn’t been tampered with?
- Can you prove that — not just assert it?
These questions didn’t appear in a vacuum. They’re the direct result of high-profile supply chain attacks, dependency hijacks, compromised CI systems, and build pipelines that quietly became an attacker’s favorite entry point.
What’s different now is that expectations are being formalized.
Greater transparency obligations
Software Bills of Materials (SBOMs) and provenance attestations are no longer niche artifacts. They’re showing up in procurement reviews, regulatory filings, and customer security questionnaires.
In the U.S., the FDA has made it clear that medical device manufacturers must demonstrate visibility into third-party software components and ongoing vulnerability management — not just at release, but throughout the product lifecycle. SBOMs are becoming table stakes, and incomplete or stale ones are already being challenged during reviews.
In the EU, the upcoming Cyber Resilience Act (CRA) raises the bar even further. It introduces mandatory requirements around secure development practices, vulnerability handling, and supply chain transparency — with penalties that look much more like product safety enforcement than traditional IT compliance.
Pressure for tamper-resistant pipelines
Modern regulations and standards increasingly assume one uncomfortable truth: build systems get attacked.
As a result, regulators are pushing organizations toward:
- Isolated, hardened build environments
- Stronger identity and access controls for CI/CD
- Cryptographic signing and verification
- Immutable, auditable logs that show who touched what — and when
This is especially visible in regulated sectors like healthcare, finance, and critical infrastructure, but the pattern is spreading quickly into enterprise software more broadly.
The implication is subtle but important: It’s no longer enough to say “we follow best practices.” You have to demonstrate that your pipeline can withstand failure, error, or attack.
Relentless scrutiny of third-party dependencies
Most organizations today ship software composed of thousands of open source components — many of them pulled automatically during builds, often several layers deep.
Regulators and auditors are starting to ask uncomfortable questions:
- How do you evaluate the integrity of components you didn’t write?
- How do you track transitive dependencies you may not even know you’re using?
- How quickly can you identify and remediate a vulnerable dependency when it surfaces?
If your answer relies on manual spreadsheets, best-effort scanning, or “we’ll look into it if asked,” you’re already behind the curve.
The real problem: noise masquerading as security
Here’s the uncomfortable truth I’ve seen over and over again: Most security and compliance programs don’t fail because teams don’t care; they fail because the signal gets lost in noise.
Hundreds of alerts. Thousands of vulnerabilities. Dozens of tools. Very little context.
When compliance pressure increases, the instinct is to add more gates, more checks, more reports. But that often slows teams down without materially improving assurance.
What regulators actually want — and what engineering teams desperately need — is clarity:
- Clear lineage of software artifacts
- Clear understanding of risk that matters
- Clear evidence that controls are real, enforced, and working
What changes in 2026
Looking ahead, I see three trends becoming unavoidable this year:
1. Compliance will move closer to product safety
Frameworks like the EU CRA signal a shift away from “reasonable effort” toward demonstrable control. Software will increasingly be treated like any other regulated product — expected to meet integrity and safety standards continuously, not just at launch.
2. Provenance will matter more than vulnerability counts
Executives will stop asking “how many CVEs do we have?” and start asking “can we prove this artifact was built correctly, from trusted sources, and hasn’t been altered?”
Provenance, integrity, and traceability will become board-level concepts.
3. Manual compliance will quietly collapse
Organizations relying on human-driven evidence collection, point-in-time audits, and ad-hoc attestations will struggle to keep up. Continuous compliance — embedded directly into pipelines — will be the only scalable path forward.
What senior executives should do next
If you’re a CISO, engineering leader, or security architect, here’s a practical checklist to get ahead of where compliance is heading:
1. Map your software supply chain
- Identify where code is sourced, built, signed, and distributed
- Understand where trust boundaries actually exist
2. Treat build pipelines as critical infrastructure
- Harden CI/CD systems
- Enforce identity, isolation, and least privilege
- Assume attackers will target them
3. Move beyond surface-level SBOMs
- Ensure SBOMs are complete, accurate, and tied to specific builds
- Track transitive dependencies continuously
4. Prioritize early, contextual security
- Find and fix issues as early as possible in development
- Focus teams on vulnerabilities that matter in context
5. Automate evidence, not paperwork
- Compliance proof should be generated as a byproduct of normal development
- If evidence requires heroics before an audit, the system is broken
If you’re subject to EU regulations, you’ll need to take a step further with the top 10 todos for CRA compliance. Proactively addressing compliance requirements will help you avoid costly, last-minute scrambles.
Where Kusari fits
Kusari exists because my co-founders and I have lived through the pain of insecure, noisy, opaque pipelines.
We’re building a world where secure software is:
- Quiet — security without constant disruption
- Transparent — clear visibility into what’s built and how
- Contextual — risk framed in a way engineers and executives can act on
Kusari helps organizations find and fix vulnerabilities early, understand transitive dependency risk, and generate verifiable evidence of software integrity — without slowing teams down.
Not because compliance demands it, but because control should be provable, not performative.
Let’s continue the conversation
If this resonates, I don’t believe the next step should be a pitch deck or a product demo.
The right starting point is a conversation about where compliance pressure is already showing up in your organization — and where it’s about to hit next.
If you’re a CISO, engineering leader, or architect wrestling with these questions, I invite you to:
- Connect with me directly — I regularly share perspectives from the field on software integrity, compliance, and secure delivery.
- Follow Kusari — we publish practical insights on building quiet, transparent, and provable software pipelines.
- Tell me when you’d like to talk — not to sell (I promise), but to compare notes on what regulators, auditors, and customers are really asking for, and how teams are responding.
Compliance is getting real whether we like it or not. The organizations that get ahead of it won’t do so by reacting — they’ll do it by understanding the shift early.
If that’s where you want to be, let’s connect.
— Tim
Like what you read? Share it with others.
.webp)
.webp)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.jpg)
Previous
No older posts
Next
No newer posts
Want to learn more about Kusari?