DevSecOps and SBOM: Enhancing DoD Software Supply Chain Security

In a world where software vulnerabilities can lead to nation-state attacks, knowing exactly what's inside your software isn't just good practice-it's a matter of national security. If the Department of Defense were to write dating app profiles for its ideal software packages, "transparent about ingredients" would be right at the top, alongside "plays well with others" and "minimal emotional baggage (read: vulnerabilities)."

The Software Supply Chain Awakening

The Department of Defense has declared its intention to evolve from a hardware-defined organization to a software-defined enterprise as part of its Fulcrum IT Advancement Strategy. This transformation isn't just a technical upgrade-it's a fundamental shift in how defense systems are conceived, built, and maintained. With software increasingly becoming the backbone of defense capabilities, ensuring its security throughout the supply chain has become paramount.

Executive Order 14028, signed by President Biden on May 12, 2021, marked a watershed moment for federal cybersecurity. This order didn't just politely suggest improvements-it mandated them, with Software Bills of Materials (SBOMs) becoming a key requirement for software vendors doing business with the federal government. Think of it as the government's way of saying, "We need to know what's in that software sandwich before we take a bite."

As of February 2025, the Army will require SBOMs for virtually all new software the service buys or builds. This isn't just another compliance checkbox-it's recognition that understanding software composition is fundamental to defense system security.

SBOM: The Digital Ingredient List

So what exactly is an SBOM? According to Executive Order 14028, it's a "formal record containing the details and supply chain relationships of various components used in building software," similar to food ingredient labels on packaging. If you've ever scrutinized nutrition facts on a cereal box, you've got the basic concept down.

But an SBOM goes far beyond simple ingredients. It creates a transparent view into the DNA of an application, identifying every component, its version, license information, dependencies, and known vulnerabilities. When a new vulnerability like Log4Shell emerges, organizations with comprehensive SBOMs can quickly identify affected systems and prioritize remediation efforts. Without this visibility, finding vulnerable components becomes the digital equivalent of finding a specific needle in a stack of very similar needles.

The National Telecommunications and Information Administration (NTIA) has outlined the minimum elements for SBOMs, which cover three key areas:

• Data fields (component identifiers, version information, etc.)
• Automation support (machine-readable formats)
• Practices and processes (generation, update procedures)

For DoD applications, these aren't just bureaucratic requirements-they're essential tools for maintaining combat readiness in an increasingly digital battlefield.

Why SBOMs Matter for Defense

The defense industrial base faces unique supply chain challenges that make SBOMs particularly valuable:

1. Decreased Supply Chain Visibility: The inability to identify sub-tier suppliers subject to foreign government direction creates significant counterintelligence risks. SBOMs help illuminate these hidden corners of the supply chain.

2. Sophisticated Cyber Threats: The DIB faces increasingly sophisticated and well-resourced cyberattacks targeting software vulnerabilities. SBOMs enable rapid identification of affected components when new threats emerge.

3. Legacy System Vulnerabilities: Many defense systems were conceived before modern cybersecurity practices, resulting in unpatched vulnerabilities that could be exploited through trusting computing relationships.

4. Foreign Dependencies: Heavy reliance on foreign nations and sole source suppliers for critical mission components creates strategic vulnerabilities. SBOMs help identify these dependencies.

The Assistant Secretary of the Army for Acquisition, Logistics, and Technology (ASA(ALT)) policy on SBOMs is particularly comprehensive, covering all programs executing across multiple acquisition pathways, including Software Acquisition, Urgent Capability Acquisition, Major Capability Acquisition, and Defense Business Systems. The policy requires Program Executive Offices (PEOs) and Program Managers (PMs) to include contract language mandating vendors deliver SBOMs for all covered computer software.

The DevSecOps Revolution in Defense

DevSecOps isn't just another tech buzzword that DoD officials use to sound current at conferences-it represents a fundamental transformation in how defense software is built, secured, and deployed.

The DoD Enterprise DevSecOps Fundamentals document defines DevSecOps as an organizational software engineering culture and practice that aims at unifying software development (Dev), security (Sec), and operations (Ops). It integrates security tools and practices into the development pipeline, emphasizes process automation, and fosters shared responsibility for security throughout the entire software lifecycle.

The DoD's approach builds upon several modern technology trends:

• The shift from waterfall methodology to Agile
• The transition from monolithic systems to modular services
• Integration of security across the technology lifecycle
• Continuous testing throughout the software lifecycle
• Evolution from traditional data centers to cloud

For weapons systems, DevSecOps environments leverage cloud along with on-premises capabilities that facilitate hardware-in-the-loop (HWIL) testing for embedded systems. This hybrid approach recognizes the unique requirements of defense systems that must integrate with physical components.

Software Factories: The DoD's Production Lines

The DoD uses "Software Factory" to describe a "collection of people, tools, and processes that enables teams to continuously deliver value by deploying software to meet the needs of a specific community of end users". These factories provide a repeatable approach to development with the goal of improving efficiency and quality.

Within these factories, securing the software supply chain is critical. The DoD Enterprise DevSecOps Fundamentals document references NIST 800-218, "Secure Software Development Framework (SSDF)," which organizes secure software development practices into four groups:

• Prepare the Organization
• Protect the Software
• Produce Well-Secured Software
• Respond to Vulnerabilities

SBOMs play a crucial role in the "Protect the Software" and "Respond to Vulnerabilities" categories, providing the transparency needed to quickly identify and remediate security issues.

Open Source Tools for SBOM Implementation

The good news for DoD program managers is that implementing SBOM doesn't require multi-million dollar contracts with defense contractors. Several powerful open-source tools exist that can generate, validate, and utilize SBOMs across the software supply chain:

Trivy by Aqua Security

Trivy has emerged as one of the most popular open-source vulnerability scanners, particularly for container images. It can detect vulnerabilities in operating system packages and application dependencies, while also generating comprehensive SBOMs in multiple formats.

For DoD applications, Trivy's ability to work in air-gapped environments makes it particularly valuable. DoD networks often operate without internet connectivity, and Trivy can be configured to use local vulnerability databases, ensuring it remains effective even in isolated environments.

Trivy can be integrated directly into CI/CD pipelines, providing automated scanning and SBOM generation with every build. This allows security teams to catch vulnerable components before they ever reach production systems.

Harbor Registry with Trivy Integration

Harbor is an open-source cloud-native registry that can store, sign, and scan container images. When integrated with Trivy, Harbor provides automatic vulnerability scanning of all container images, with configurable policies to prevent vulnerable containers from being deployed.

Daniel Pacak from Aqua Security demonstrates how this integration works: "Harbor is an open source cloud-native registry, and Trivy is a container image vulnerability scanner. The integration allows for scanning a sample Node.js application for vulnerabilities". This combination provides a powerful foundation for securing container deployments across DoD environments.

For program managers concerned about compliance, Harbor + Trivy can be configured to enforce policies based on vulnerability severity, ensuring that containers with critical vulnerabilities are never deployed to production environments.

Syft by Anchore

Syft specializes in generating SBOMs from container images and filesystems. It produces detailed component listings in multiple formats, including CycloneDX, SPDX, and Syft's native JSON format.

For DoD applications handling sensitive data, Syft's ability to work fully offline is particularly valuable. It can analyze air-gapped systems without requiring internet connectivity, ensuring that even the most secure environments can benefit from SBOM capabilities.

Syft integrates seamlessly with other security tools in the DevSecOps pipeline, making it an ideal component in a comprehensive security strategy. Its detailed output allows security teams to quickly identify vulnerable components and take appropriate action.

Other Notable Open Source SBOM Tools

Several other open-source tools deserve mention for specific DoD use cases:

• OWASP Dependency-Check: Particularly strong for analyzing application dependencies across multiple languages.
• CycloneDX CLI: Created by the OWASP Foundation, it provides utilities for working with CycloneDX SBOMs.
• SPDX Tools: Maintained by the Linux Foundation, these tools support the SPDX SBOM format.
• Fossa: Focuses on license compliance alongside vulnerability detection.

Each tool offers capabilities tied to different stages of the software lifecycle, with varying ecosystem coverage, license detection capabilities, and SBOM format support.

Making SBOMs the Gateway to Your DevSecOps Pipeline

In the commercial world, consumers check ingredient labels before eating food. In the DoD world, the same principle should apply to software: nothing gets consumed without knowing what's inside.

As Anchore suggests, "The time is now to make an SBOM the entry gate for commercial and OSS to enter your DevSecOps toolchain and software supply chain". This approach provides several key benefits:

1. Early Risk Identification: Catching vulnerable components before they enter the pipeline reduces remediation costs and security risks.

2. Vendor Accountability: Requiring SBOMs from vendors ensures they take responsibility for the security of their products.

3. Continuous Monitoring: With complete SBOMs, security teams can continuously monitor for new vulnerabilities affecting existing components.

4. Compliance Documentation: SBOMs provide documentation that can be used to demonstrate compliance with security requirements.

For DoD program managers looking to implement this approach, Anchore recommends three strategies:

1. Make SBOMs Contractual Requirements: Include SBOM delivery as a requirement for all software vendors and partners.

2. Establish Cross-Functional Collaboration: Use SBOMs as a tool for collaboration between contracts, finance, development, and cybersecurity teams.

3. Deputize SBOM Owners: Assign responsibility for generating and maintaining SBOMs to specific team members or groups.

Implementation Strategies for DoD Environments

The U.S. Army's approach to SBOM implementation provides a useful model for other DoD components. According to their policy, Program Executive Offices (PEOs) and Program Managers (PMs) must codify processes for SBOM collection, storage, management, and continuous monitoring within 90 days after receiving guidance.

A key element of the Army's strategy is the establishment of a cross-PEO/PM SBOM Working Group to facilitate knowledge exchange and promote collective problem-solving around SBOM implementation. This collaborative approach recognizes that SBOM implementation is a learning process that benefits from shared experiences.

For DoD decision makers considering SBOM implementation, several practical strategies can accelerate adoption:

1. Start with New Acquisitions

Rather than attempting to retroactively generate SBOMs for all existing systems, focus initially on requiring SBOMs for new software acquisitions. The Assistant Secretary of the Army for Acquisition, Logistics, and Technology (ASA(ALT)) policy requires contract language mandating SBOMs for all covered computer software.

Sample contract language might include: "Vendor shall deliver a comprehensive Software Bill of Materials (SBOM) in CycloneDX format for all delivered software, identifying all components, their versions, and known vulnerabilities."

2. Integrate with Existing Security Processes

Rather than creating separate processes for SBOM management, integrate them with existing security workflows. For example, vulnerability management teams can use SBOMs to quickly identify affected systems when new CVEs are published.

The DoD's Continuous Authority to Operate (cATO) approach depends on robust information security continuous monitoring capabilities, which SBOMs can enhance. By incorporating SBOM analysis into continuous monitoring processes, security teams can maintain ongoing awareness of supply chain risks.

3. Leverage Cloud-Native Patterns

For systems leveraging cloud technologies, implementing SBOM generation and analysis in cloud-native environments can be particularly effective. The DoD Enterprise DevSecOps Fundamentals document notes that "Cybersecurity elements will leverage cloud service provider (CSP) managed service capabilities where practicable".

Harbor + Trivy provides an excellent example of cloud-native SBOM implementation. By scanning container images at rest in the registry, this approach ensures that all deployed containers have been analyzed for vulnerabilities before deployment.

4. Build Automated Feedback Loops

The power of SBOMs is fully realized when they're integrated into automated security processes. As the DoD guidance suggests, "Teams will aggressively seek to integrate automated feedback, patching, alerting, and other authorized network security measures".

For example, an automated system could:

1. Generate SBOMs during the build process using Syft
2. Store SBOMs in a central repository
3. Continuously monitor for new vulnerabilities affecting identified components
4. Automatically create tickets for remediation when vulnerabilities are discovered
5. Prevent deployment of vulnerable components based on configurable risk thresholds

Addressing SBOM Implementation Challenges

While SBOMs offer significant security benefits, implementation does face several challenges that DoD program managers should anticipate:

Format Standardization

The lack of a single standard format for SBOMs creates compatibility challenges. As noted in the search results, "Each has its own schema and capabilities, which can create compatibility issues when integrating SBOMs across different tools and platforms".

To address this challenge, DoD organizations should standardize on a single format internally while maintaining the capability to convert between formats as needed. The CycloneDX format is particularly well-suited for DoD use cases, as it's "approved by the U.S. government" and provides comprehensive coverage of security-relevant attributes.

Vendor Cooperation

Obtaining complete and accurate SBOMs from software vendors can be challenging, particularly for commercial off-the-shelf (COTS) products. The Army's policy addresses this by requiring contract language mandating SBOM delivery.

For vendors resistant to providing SBOMs, DoD organizations can explore alternative approaches:

• Generate SBOMs through software composition analysis tools
• Use container scanning tools that enable SBOM generation
• Implement progressive procurement policies that favor vendors providing SBOMs

Retroactive Generation Limitations

As noted in the NIST guidance, "SBOMs that are retroactively generated may not be able to produce the same list of dependencies used at build time". This limitation is particularly relevant for legacy systems where original build information may be unavailable.

For these systems, a risk-based approach is appropriate, focusing SBOM efforts on mission-critical systems or those with known security concerns. The NIST guidance suggests that "federal acquirers should continue using the risk-based approaches outlined in SP 800-161r1 and SP 800-218 to guide their implementation of SBOMs".

The Road Ahead for DoD Software Supply Chain Security

The DoD's software supply chain security journey won't end with SBOM implementation. As threat landscapes evolve, so too must defensive capabilities. Several emerging trends will shape the future of this space:

Integration with Zero Trust Architecture

The DoD Zero Trust Strategy provides a framework for security that aligns well with SBOM capabilities. By providing detailed component information, SBOMs enable more granular trust decisions about software components, supporting the zero trust principle of "never trust, always verify."

Future implementations will likely integrate SBOM data directly into zero trust decision engines, allowing for automated policy enforcement based on software composition.

Blockchain-Based SBOM Distribution

Emerging research explores using blockchain technology to enhance SBOM integrity and distribution. As one paper notes, "This paper introduces blockchain technology into the SCA system, utilizing smart contracts to provide core SBOM tool services and microservices to improve the operational efficiency".

This approach could address current challenges with SBOM trust and verification, ensuring that SBOMs cannot be tampered with after creation and providing a transparent chain of custody.

STPA-Sec Analysis for DevSecOps

The System-Theoretic Process Analysis approach for Security (STPA-Sec) offers a promising methodology for understanding and eliciting systems security requirements for Software Factories. This approach develops "functional-level security requirements, design-level engineering considerations, and architectural-level security specification criteria early in the system life cycle".

By integrating STPA-Sec analysis with SBOM capabilities, DoD organizations can develop more comprehensive security strategies that address both component-level and system-level vulnerabilities.

A More Secure Software Future

The journey toward comprehensive software supply chain security in the DoD is neither quick nor simple. It requires cultural shifts, process changes, and new technological capabilities. Yet the imperative is clear: as software increasingly defines defense capabilities, understanding and securing that software is a national security requirement.

SBOMs provide the foundation for this security, offering transparency in an increasingly opaque software ecosystem. When integrated into DevSecOps practices, they enable automated, continuous monitoring of software supply chain risks throughout the development and operational lifecycle.

For DoD decision makers, the question isn't whether to implement SBOMs, but how quickly and effectively they can be integrated into existing processes. The Army's February 2025 mandate provides a clear timeline, but organizations shouldn't wait until the deadline to begin implementation.

By leveraging open-source tools like Trivy, Harbor, and Syft, DoD organizations can implement SBOM capabilities without massive investments in proprietary solutions. These tools provide immediate value while aligning with longer-term strategic goals for software security.

The software battlefield of tomorrow demands transparency today. As one security expert put it, in a world of increasing software complexity, not knowing what's in your software is like not knowing what's in your foxhole. And in either case, what you don't know can definitely hurt you.