Key takeaways
- AI-generated code is increasing software velocity, but it’s also making provenance, dependency management, and remediation much harder to govern in regulated environments.
- SSDF and SLSA help organizations prove that software is secure and built through repeatable processes that auditors can trust.
- FedRAMP auditors increasingly want evidence of provenance, SBOM management, secure build pipelines, and vulnerability remediation velocity.
- ActiveState helps organizations create a more controlled software supply chain with trusted open source components, signed artifacts, continuously updated SBOMs, and ongoing remediation support.
What happens when your software supply chain grows faster than your ability to trust it?
That is the question sitting underneath almost every FedRAMP audit and boardroom security conversation right now.
Tools like Claude Code, GitHub Copilot, and other AI coding assistants are helping developers generate and ship code at a velocity that most governance models were never designed to handle. For security and development teams, that shifts the conversation from productivity to liability.
The recent Claude Code leak is a good example. After Anthropic exposed more than 500,000 lines of internal source code, researchers uncovered packaging issues, prompt injection risks, weak deny rules, and paths for unsafe command execution.
For regulated organizations, the lesson is rather simple: AI-generated code expands your attack surface faster than manual review and “spreadsheet governance” can keep up. The more code AI generates, the more open source dependencies, packages, containers, and build artifacts your teams need to control.
That is exactly why frameworks like the secure software development framework (SSDF) and supply-chain levels for software artifacts (SLSA) are becoming more important in FedRAMP and other regulated environments.
Auditors are no longer satisfied with a vulnerability scan and a policy document. They want proof that you know where your software came from, how it was built, which dependencies entered production, and how quickly you can respond when something goes wrong.
For security and development teams, the question to ask isn’t whether or not AI-generated code belongs in the software development lifecycle (SDLC). It already does. The right question to ask is whether your organization has the controls, processes, and evidence in place to govern it safely.
Why do SSDF and SLSA matter more in FedRAMP environments?
SSDF and SLSA help regulated organizations answer two different, but equally important, questions:
Do we have secure software development practices in place?
This question focuses on how software is built, including whether developers follow secure coding standards, whether vulnerabilities are properly triaged and remediated, and whether third-party components are reviewed before entering production.
Can we trust the software itself?
This question focuses on the integrity and provenance of the software, including whether you can prove where a package came from, trace how it was built, and verify that it hasn’t been tampered with between development and deployment.
Neither framework is mandatory in FedRAMP environments today, but both are becoming important signals of maturity, especially as AI-generated code, open source dependencies, and software supply chain risks continue to grow.
For auditors, they’re busy assessing whether you can produce evidence of control, provenance, and repeatability across your software lifecycle. SSDF and SLSA, then, help your organization prove that security is not happening ad hoc, but as part of a documented and repeatable process.
Definitions
Secure software development framework (SSDF)
SSDF is a framework developed by National Institute of Standards and Technology that helps organizations build security into every stage of the software development lifecycle, from secure coding and code review to vulnerability remediation and supplier oversight.
Supply-chain levels for software artifacts (SLSA)
SLSA is a security framework designed to help organizations prove the integrity and provenance of their software by establishing controls around how code is built, signed, traced, and protected from tampering.
What are FedRAMP auditors looking for?
FedRAMP audits have become far more technical than many organizations expect, and it’s no longer enough to just “show” that security policies exist on paper.
Auditors increasingly want to understand how your software is actually moving through the SDLC, where risk enters the process, and whether your team can contain that risk before it reaches production.
So, what are they looking for exactly?
1. Provenance and traceability
Auditors want to know where your software came from. That includes your code, open source packages, dependencies, containers, and build artifacts.
Can you trace a deployed application back to its source code, build environment, SBOM, and approval process? Can you prove that a package was sourced from a trusted location and not pulled directly from an unverified public registry? In regulated environments, provenance is becoming just as important as the code itself.
2. SBOMs that are actually usable
Auditors increasingly want living SBOMs that can be updated, searched, and tied back to deployed systems. When a new vulnerability emerges, they want to know whether your team can quickly identify where that vulnerable component exists, understand the blast radius, and begin remediation immediately.
3. Secure build pipelines and signing
FedRAMP auditors also want evidence that your build process itself is secure. That means secure CI/CD pipelines, signed artifacts, controlled build environments, reproducible builds, and protections against tampering. If you cannot prove how a build was created or whether it changed between development and deployment, auditors will see that as a major gap.
4. Vulnerability remediation velocity
Every organization has vulnerabilities. Auditors know that. What matters more is how quickly you can identify, prioritize, and remediate them. They want to see documented SLAs, evidence of remediation workflows, and proof that critical vulnerabilities are not sitting unresolved for months.
Where most organizations still fall short when it comes to FedRAMP compliance
Too many organizations are still focusing on rudimentary compliance measures instead of focusing on the work required to keep them updated. They run vulnerability scans but lack a clear remediation process, for example. Or, they rely on public registries for open source packages but cannot prove provenance or explain how those components entered production.
Manual approvals are another common weak point. They may work when development teams are small, but they do not scale when hundreds of developers and AI coding tools are introducing new packages and dependencies every day.
This is often where regulated organizations get stuck. They may technically pass an audit, but they still lack the controls, traceability, and remediation processes needed to reduce real risk. And it’s this gap between compliance and actual security that is exactly what auditors are becoming better at identifying.
How ActiveState helps organizations prove control
ActiveState helps organizations create a more controlled and auditable software supply chain by giving teams access to a curated catalog that pulls from a library of more than 79 million secure, vetted open source components.
Instead of relying on public registries and manual reviews, teams can work from approved packages with known provenance, signed artifacts, and continuously updated SBOMs.
This matters in FedRAMP environments because it creates evidence.
Rather than relying on point-in-time scans, organizations can rely on ActiveState to show where packages came from, how they were built, what dependencies entered production, and how vulnerabilities are being remediated over time.
ActiveState also integrates directly into existing CI/CD pipelines and AI coding workflows, helping teams maintain developer velocity without sacrificing governance or disrupting existing processes.
For CISOs and dev leaders, that means less manual oversight, less uncertainty, and fewer blind spots in an environment where AI is making software supply chains harder to trust.
Build the evidence before the audit arrives
AI is increasingly taking on core engineering tasks such as refactoring, application modernization, test generation and dependency updates across the SDLC.
In fact, McKinsey reports that more than 90% of software teams now use AI for at least some of these activities, saving developers an average of 6 hours per week. At the same time, tools like GitHub Copilot, Claude Code, and Google Jules are evolving from assistive coding tools into reasoning-driven agents that can plan tasks, recommend dependencies, and execute changes with minimal human involvement.
That is good news for developer velocity. But it’s not always good news for governance.
As AI becomes more deeply embedded into the SDLC, frameworks like SSDF and SLSA give organizations a way to prove that their software is secure, traceable, and maintainable. Ultimately, they help teams move beyond mere policy documentation toward something much more valuable: evidence.
Frequently Asked Questions
FedRAMP, SSDF, SLSA, SBOMs, and AI-generated code can all feel overwhelming, so here are answers to some of the most common questions security leaders are asking right now.
SSDF focuses on secure software development practices across the SDLC, including secure coding, vulnerability management, code review, and supplier oversight. SLSA focuses more specifically on software provenance, build integrity, artifact signing, and protecting the software supply chain from tampering.
SSDF is not formally required in every FedRAMP environment, but it is increasingly being used as a framework to demonstrate secure development maturity. Many of its practices align closely with what FedRAMP auditors already expect to see.
SLSA helps organizations prove where software came from, how it was built, and whether it has been tampered with. In regulated environments, that kind of traceability and provenance is becoming increasingly important as software supply chain risks continue to grow.
AI-generated code can introduce unknown dependencies, outdated packages, insecure configurations, and weak provenance. As AI tools generate more code at greater velocity, it becomes harder for organizations to manually review, trace, and govern everything entering production.
ActiveState helps organizations improve provenance, traceability, SBOM management, vulnerability remediation, and secure open source usage. With access to more than 79 million vetted open source components, teams can reduce risk and create the evidence auditors increasingly want to see.
