Software Supply Chain Security Regulations From a DevSecOps Perspective

Editor's Note: The following is an article written for and published in DZone's 2025 Trend Report, Software Supply Chain Security: Enhancing Trust and Resilience Across the Software Development Lifecycle.

High-profile software supply chain attacks like SolarWinds, Log4j, and MOVEit highlight the urgent need to address the vulnerabilities caused by insecure software supply chains, prompting a decisive regulatory response. In the United States, entities like the Federal Trade Commission (FTC), the Computer Fraud and Abuse Act, and emerging state laws are already being used to penalize companies that contain or distribute vulnerable or malicious code. Meanwhile, Europe's Cyber Resilience Act and new Product Liability Directive impose stricter cybersecurity obligations, heavy fines, and even personal accountability for software-related harm.

This isn't just paperwork. Failing to securely manage dependencies and maintain accurate dependency records now means significant liability and legal accountability for CISOs. In today's regulatory environment, compliance is central to DevSecOps. However, if these processes are not properly automated and implemented, regulations could stifle the very agility DevSecOps was born to deliver.

This article aims to provide an overview of key regulations related to software supply chain security, discuss their implications in organizations, and explore their impact on DevSecOps teams.

Regulatory Landscape Overview

You can't patch what you don't know. To address this critical visibility gap, global software supply chain security regulations are emerging, establishing accountability within organizations.

These regulations mandate that software vendors provide a detailed inventory of all direct and transitive dependencies, including open-source libraries and third-party components, embedded within their software products. The primary objective behind this granular transparency is to ensure that only attested, secure packages are utilized in the software stack. 

This regulatory push reflects a global consensus: A thorough understanding of software composition is fundamental to effectively mitigate the critical security risks that stem from insecure, unpatched dependencies.

For information system auditors and security assessors, precise package names or identifiers, versioning information, and supplier details are critical artifacts. Integrating this granular dependency data into audit processes allows for an in-depth assessment of the organization's software attack surface. This facilitates the identification of risks such as:

• Components with unpatched critical vulnerabilities
• End-of-life software
• Unauthorized or unlicensed packages
• Deviations from internal security policies
• Non-compliance with external regulatory compliance frameworks

Key Existing Regulations

Software bills of materials (SBOMs) have emerged as a critical foundation for transparency into software composition. However, SBOMs don't solve the problem by themselves — they're a tool, not a silver bullet. An SBOM is merely a detailed list; without automated tooling to correlate its contents with real-time vulnerability intelligence and contextual risk, it could become an artifact with limited immediate security utility, potentially devolving into a compliance checkbox. But for regulators, it is an essential data source for effective security practices and vendor accountability for product integrity and security.

The evolution of SBOMs has been significantly shaped by an evolving regulatory landscape, transitioning them from a niche best practice to an increasingly mandated compliance requirement. This systemic shift requires integrated, cross-functional collaboration between development, security, and legal stakeholders.

U.S. Regulatory Initiatives

Issued in the United States after the SolarWinds incident, Executive Order 14028 mandates secure software development and supply chain risk management, directing the NIST to develop SBOM guidelines for federal procurement. (Note: The June 6, 2025 U.S. EO rolled back SBOM requirements for vendors, but EO 14028 can still be used as a foundation). NIST SP 800-218 (SSDF) provides actionable guidance, recommending SBOMs to mitigate supply chain risks and complementing EO 14028. NIST SP 800-53 details federal security controls, including controls for supply chains. CISA also recommends the use of SBOMs.

The National Telecommunications and Information Administration (NTIA) SBOM has released a document that serves as a benchmark for SBOM practices and defines the minimum SBOM elements:

• Supplier
• Component name
• Component version
• Unique identifiers
• Dependency relationship
• Author of SBOM data
• Timestamp

While these U.S. efforts are largely complementary, federal agencies can legally request SBOMs for software they designate as "critical." The definition of "critical software," however, is not strictly specified and often varies by agency. This ambiguity frequently requires the involvement of legal teams in discussions about software dependencies and in handling regulatory SBOM requests.

EU Regulatory Initiatives

The European Union is also raising the bar. The Cyber Resilience Act, broader than any single U.S. mandate, treats software like a consumer good. It imposes on manufacturers obligations to meet minimum security standards, apply patches, perform vulnerability disclosures, and provide technical documentation, including an SBOM, for 10 years after market entry.

The Digital Operational Resilience Act (DORA) targets the financial sector's ICT and third-party supply chain risk. The NIS2 Directive broadens cybersecurity requirements for essential and important entities, encompassing supply chain security and requiring member states to adopt relevant policies. These EU regulations are complementary, addressing product security (CRA), financial resilience (DORA), and critical entity network security (NIS2).

Although all these regulations differ in direct legal force and target audience, they universally recognize the critical need for software composition transparency, secure development practices, proactive vulnerability management, improved incident response, and increased transparency and trust.

Impact on DevSecOps Practices

Despite the regulatory mandates requiring changes, the "how to" often remains unclear, creating challenges for development, security, operations, and legal teams trying to adapt. Actually, it is concerning how few organizations feel adequately prepared or confident in their strategies for securing their software supply chains. For example, a recent RSA Conference survey showed a mere 20% of companies could meet the CISA's software development attestation deadline. Is the primary difficulty simply the lack of precise technical steps, or does it point to deeper issues in how these teams approach shared security responsibility? I would argue this isn't simply a technical challenge, but predominantly a cultural one.

If developers don't genuinely buy into the culture, they're likely to see compliance mandates as roadblocks, not as essential security improvements. That's why building a compliance-first culture is critical. This means actively rewarding secure-by-default approaches, making compliance a natural part of engineering workflows, and elevating compliance artifacts, such as SBOMs and provenance logs, to be core components of your development ecosystem.

Organizations now require a coordinated effort where development teams generate SBOMs, security teams validate artifact signatures, and operations teams ensure only compliant images are allowed to be deployed.

Achieving regulatory compliance at scale requires a fundamental shift, moving away from legacy manual workflows toward an automated ecosystem. In this model, enforceable, Policy-as-Code practices are integrated into continuous integration and continuous delivery (CI/CD) pipelines to meet demands without creating friction in development teams.

Additionally, for DevSecOps teams operating in regulated industries, traceability is no longer optional — it's a fundamental compliance mandate directly impacting pipeline design. To meet this, integrating supply chain security tools like Tekton Chains and Sigstore directly into CI/CD workflows becomes critical for automatically generating cryptographic proof of every action. Furthermore, DevSecOps practices must evolve to incorporate systems that ensure non-repudiation via mechanisms like signed attestations to provide thorough auditability and complete security traceability that regulators now demand.

When incorporating open-source code, development teams need to be acutely aware of the potential regulatory implications, especially if these packages have known vulnerabilities (CVEs). The best practice, of course, is to avoid packages with known CVEs when possible, but if not, a well-documented justification is critical for regulatory due diligence. This is why, as you define your supply chain security practices, it's essential to ensure procurement and legal teams have a seat at the table.

The following are some of the key ways effective DevSecOps teams are implementing software supply chain security regulatory mandates.

Automation of SBOM Generation in CI/CD

Think of SBOMs as living documents, not one-time snapshots. Regulators and standards require the automatic creation of an SBOM every time you build your software. Tools like Syft, Trivy, or CycloneDX plugins for Maven/Gradle can achieve this directly in the CI/CD pipeline before or during release. This means that everyone who needs to know what packages are used in your software gets an up-to-date SBOM, not an old one.

There might be rare cases where these tools will not auto-detect some packages. In such cases, you'll still need to manually add any missed packages in the SBOM for completeness.

Another best practice is to adopt a single SBOM format across all projects in the organization and enforce this via pipeline policies.

SBOM Validation and Deployment Gates

Just having an SBOM isn't enough. In a secure environment, we also need to know:

• Can we trust it?
• Has it been tampered with?
• Is it authentic?

Thus, regulations also require DevSecOps teams to perform SBOM validation and gated deployments. 

To address this, digital signatures, hashing, and attestations are critical for verifying and validating SBOMs. And of course, modern DevSecOps pipelines embed these validation and compliance checks as code, with cryptographic attestations and policy enforcement gates built into every stage of the software development lifecycle (SDLC).

A best practice is to integrate SBOM validation, including provenance verification, into CI/CD deployment gates using Policy as Code, such as Open Policy Agent (OPA) and Kyverno. Kubernetes admission controllers can enforce this by verifying signatures and compliance data. Using dependency scanning and license compliance checks in deployment gates ensure only secure, compliant, and signed artifacts with vetted dependencies are released.

Storing and Versioning SBOMs Securely

SBOMs must be immutable, tamper-evident, and readily accessible for audits or incident response. This creates a challenge. Some organizations store SBOMs alongside container images in artifact registries, while others use dedicated metadata servers.

Solutions are now emerging to address versioning and metadata creation in software supply chains, such as Sigstore's Rekor. By leveraging an immutable and tamper-resistant ledger, software vendors and build systems can record signed metadata about software projects. This practice enables downstream parties to confidently make decisions regarding an object's trust and lifecycle, backed by non-repudiable evidence.

Best Practices for Ensuring Security and Compliance

The following outlines best practices to effectively ensure both security and compliance throughout the software supply chain.

Document Known Unknowns

Known unknowns might be one of the most challenging problems in software supply chain security. As described by the NTIA and NIST, there can be instances in which the full dependency graph is not enumerated in the SBOM. In these situations, the SBOM author must clearly flag such "known unknowns."

An SBOM must clearly indicate whether the dependency information for a particular component is complete, partial, or unavailable, and explain the reason for any gaps. This prevents consumers of the SBOM from making dangerously optimistic assumptions about the completeness of the data, ensuring a more realistic assessment of potential risks stemming from unlisted or unanalyzed dependencies. 

One solution I have found valuable in addressing the known unknown challenge is using runtime monitoring tools such as IAST. Runtime monitoring enables us to identify the known unknown dependencies and verify whether they are actually loaded or executed. This way, we can follow a risk-based vulnerability management strategy as required by the EU CRA and the NIS2 Directive.

Adopt Regulations While Maintaining Dev Velocity

It's not uncommon for teams to be concerned that regulatory demands on DevSecOps will slow down their development velocity. However, this perception often stems from outdated approaches. Regulations don't inherently have to be blockers; when security and compliance practices are automated and embedded early into the lifecycle — think "shift left" — they transform into enablers, not roadblocks.

If your developers are bogged down filling out manual compliance checklists, it's a clear sign your implementation needs rethinking. Automating supply chain integrity isn't just good security hygiene; it's the only strategy to maintain your development velocity while achieving compliance.

Eliminate SBOM Sprawl

The proliferation of SBOMs — potentially one for every image, build, or microservice — can lead to an unmanageable volume without proper indexing and deduplication strategies, a challenge commonly termed "SBOM sprawl." I would argue that we should handle SBOMs using the same level of lifecycle management as production data, and apply data governance, retention, and archival or clean-up policies. Centralized aggregation and analysis platforms, such as Google's Graph for Understanding Artifact Composition (GUAC), are emerging to address this. These systems can provide a unified view of software components and their interdependencies, enhance our supply chain vulnerability visibility, help vulnerability management efforts, and improve compliance tracking.

Eliminate Slopsquatting

AI code suggestion tools, like ChatGPT or Cursor, can sometimes "hallucinate" and recommend code or dependencies that seem plausible but are actually incorrect, insecure, or outright malicious. This is often called "slopsquatting" and effectively sabotages the software supply chain. I've personally seen LLMs propose dependencies that are cleverly typosquatted or malicious packages, but they look like legitimate ones.

To address the risk introduced by AI code suggestion tools, a critical first step is configuring these AI assistants to prioritize our own vetted, internal libraries over public repositories. But that's not enough. To catch these insecure or non-compliant dependencies that slip through due to AI hallucinations, we also need rigorous dependency validation using automated allow-lists, backed by robust software composition analysis (SCA) tools.

Continuous Monitoring and Auditing of Software Supply Chains

True supply chain diligence requires continuous monitoring. The following monitoring practices are mandated by regulations:

• Constantly scanning for new CVEs affecting deployed components
• Proactively implementing immediate alerts for drift, violations, or new critical vulnerabilities
• Regularly reviewing and updating your supply chain risk management processes to keep pace with organizational and regulatory changes

Adopt SLSA to Adapt to Evolving Regulations

Supply-chain levels for software artifacts (SLSA) offer a practical framework to meet increasing software supply chain security regulations. By providing incremental, verifiable levels of assurance against tampering and unauthorized modification, SLSA helps organizations demonstrate the integrity and provenance of their software artifacts. Adopting SLSA levels can provide auditable evidence of secure build practices and artifact handling, directly addressing many regulatory demands for greater supply chain visibility, security, and due diligence, thereby easing compliance burdens.

Conclusion

It's clear now that effective "security by design" fundamentally begins with a secure supply chain. Regulations are directly influencing software design and processes, and these mandates are also becoming more complex. However, if we treat compliance like any other technical problem — and build it into our DevSecOps tools and automation, while investing in standards and team knowledge — we can achieve compliance efficiently. 

Keep in mind that although the software supply chain is global, regulations themselves are not, leading to different jurisdictions having varying requirements for SBOMs. Consequently, DevSecOps teams and security auditors must stay up to date on the latest developments in their specific regions to ensure awareness of the most current and applicable regulatory requirements.

In the future, SBOMs will play a big part in secure software development and supply chain management. Leveraging them through robust DevSecOps automation is becoming essential for any organization's proactive regulatory compliance strategy and overall security.

References and additional resources:

• Software Supply Chain Security by Justin Albano, DZone Refcard
• SBOM Essentials by Siri Varma Vegiraju, DZone Refcard
• "How To Implement Supply Chain Security in Your Organization" by Kellyn Gorman
• "NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations" by Jon Boyens et al
• Leader's Guide to Software Supply Chain Security, Gartner
• "Gartner Predicts Half of Supply Chain Management Solutions Will Include Agentic AI Capabilities by 2030," Gartner
• "LLMs can't stop making up software dependencies and sabotaging everything" by Thomas Claburn
• SLSA, Safeguarding artifact integrity across any software supply chain
• "Report: Only 1 in 5 organizations have full visibility into their software supply chain" by Jenna Barron

This is an excerpt from DZone's 2025 Trend Report, Software Supply Chain Security: Enhancing Trust and Resilience Across the Software Development Lifecycle.

Read the Free Report