The Rise of Agentic Coding
In recent years, we’ve seen an evolution from traditional software engineering to agentic coding—where autonomous AI agents can generate, modify, and deploy code with minimal human oversight. These AI systems can spin up microservices, refactor APIs, or integrate third-party libraries in seconds. While this has accelerated innovation, it has also introduced a new layer of complexity into application security.
Each automated code generation introduces potential risks:
- Unverified open-source dependencies
- Outdated libraries with known vulnerabilities
- Hidden transitive packages that evade manual review
The challenge isn’t just what AI can build—it’s what it pulls in behind the scenes.
Why SBOMs Are the New Security Baseline
A Software Bill of Materials (SBOM) is a formal record of all components, libraries, and dependencies that make up a software application. Think of it as an ingredient list for your software.
In the age of agentic coding, an SBOM is critical for:
- Transparency: Knowing exactly which components and versions are in use.
- Vulnerability Management: Quickly identifying when a known CVE affects your environment.
- Compliance: Aligning with mandates like U.S. Executive Order 14028 and NIST SP 800-218, which require SBOMs for federal software.
- AI Governance: Auditing the provenance and trustworthiness of AI-selected components.
Without an SBOM, your organization risks operating a “black box” system where even developers can’t confidently describe what’s running in production.
Challenges in the AI-Driven Era
SBOMs are only as accurate as the processes that maintain them. In traditional DevSecOps pipelines, SBOM generation occurs during build or release stages. With agentic coding, new dependencies can appear dynamically—outside the boundaries of CI/CD.
To adapt, organizations must:
- Implement continuous SBOM generation during runtime and deployment.
- Integrate AI observability to track which agents are sourcing or modifying code.
- Employ dependency integrity validation (e.g., digital signing and checksum verification).
Integrating SBOMs into Secure Development Pipelines
Modern security platforms like OpenText Fortify, Checkmarx One, and Trivy can automate SBOM creation and vulnerability scanning. Combining SBOM data with Software Composition Analysis (SCA) tools provides a real-time map of your software’s risk posture.
A practical workflow might look like this:
- Code generation: AI agents create or modify code.
- SBOM scan: Automatically generate or update the SBOM (CycloneDX or SPDX format).
- SCA & CVE checks: Evaluate dependencies for known vulnerabilities.
- Governance policy enforcement: Block deployment if risk thresholds are exceeded.
This ensures your application remains compliant, secure, and traceable—even when AI is doing the heavy lifting.
Looking Ahead
Agentic coding will continue to push the boundaries of what’s possible in software delivery. But with that power comes the responsibility to maintain transparency and control.
By embracing SBOMs as a living artifact—not a compliance checkbox—organizations can keep pace with AI-driven innovation without compromising security or trust.
Key Takeaways
- Agentic coding introduces unseen dependencies that traditional methods might miss.
- SBOMs provide essential visibility into software composition and supply chain risks.
- Continuous, automated SBOM generation is the next frontier of DevSecOps maturity.
- Trust in AI-assisted development begins with transparency in what your software is made of.
FAQ section:
- What is an SBOM? An SBOM is a formally structured list of all components, libraries and modules that make up a piece of software and the supply‑chain relationships between them. Both NTIA and the ACT‑IAC definition compare it to a “nested inventory” or ingredient list.
- Who uses an SBOM and for what? SBOM usage falls into three broad categories: producers use it to maintain their software, purchasers use it for pre‑purchase assurance and to plan implementations, and operators use it to manage vulnerabilities, licenses and supply‑chain risks.
- Who should have or produce an SBOM? NTIA notes that anyone concerned with supporting their software products and customers should generate SBOMs; requirements may emerge for regulated sectors, such as the FDA’s mandate for medical device manufacturers.
- What should be included in an SBOM? Minimum elements include the author’s name, supplier name, component name, version string, a component hash or unique identifier, and the relationship between components; licensing and provenance information should also be included if available.
- Why are SBOMs important? SBOMs improve transparency and security across the software supply chain. Benefits cited in industry guidance include better identification of software components, improved detection of vulnerabilities, faster remediation, greater transparency and customer trust, improved licensing governance and enhanced supply‑chain resiliency.
- How often should an SBOM be updated? NTIA advises that a new SBOM should be created for every new release of a component; any change to a component requires a corresponding update to the SBOM. FDA‑focused guidance similarly notes that SBOMs must be updated whenever software components change.