Your own code is only part of what reaches production. Open-source libraries, frameworks, container images and build tools can contain vulnerabilities or become attack paths. Responding is difficult without knowing what your software contains.
Direct and transitive dependencies
Direct dependencies are libraries your team deliberately adds. Transitive dependencies are brought in by those libraries, potentially introducing many packages nobody selected individually.
Transitive components are easily overlooked: they may not appear in the main project manifest, and updates depend on upstream maintainers. When a deeply nested package becomes vulnerable, the first question is whether and where you use it.
Package managers generally show dependency trees. Inspecting one is a useful first step, but ongoing records are needed for timely answers.
SBOM as an ingredient list
A Software Bill of Materials is a machine-readable component inventory. CISA compares it to an ingredient list. It includes component names, versions, suppliers, relationships and often licences.
Two widely used open formats are:
- CycloneDX, maintained through OWASP and Ecma International and published as ECMA-424.
- SPDX, also published as ISO/IEC 5962:2021.
Many build and analysis tools support both. Automatic generation for each build and correspondence to the deployed version matter more than the choice. Manual lists quickly become outdated. Container base images also include OS packages needing inventory and updates.
Some customers require SBOMs during supplier selection. The EU Cyber Resilience Act, Regulation (EU) 2024/2847, also requires manufacturers of covered products with digital elements to document at least top-level dependencies in an SBOM. The Commission states that main obligations apply from 11 December 2027. Assess applicability to your product against the legislation.
SCA: continuous assessment
Software Composition Analysis compares components against vulnerability and licence databases, using source, built artefacts or SBOMs. OWASP Dependency-Track, for example, continuously analyses SBOMs and alerts on newly disclosed vulnerabilities.
SCA output is not a ready-made task list. Vulnerable functionality may be unused or unreachable, while a modest-looking issue in user-input processing may be important. Assess findings in application context.
Useful practices include:
- Check every build and block only clearly defined conditions.
- Monitor newly disclosed vulnerabilities in deployed versions too.
- Prioritise severity and reachability to avoid overwhelming teams.
- Record why findings are considered non-exploitable.
Update and package selection rules
Without rules, updates often happen only after problems. Establish a few principles:
- Set risk-based deadlines for critical security fixes.
- Perform routine updates regularly, such as each sprint or monthly.
- Use lock files to pin versions and reproduce builds.
- Track unmaintained components and plan replacements.
Review new packages too. Attackers use typosquatting, abandoned package takeover and compromised maintainer accounts. Check exact names, maintainers, release history and project activity. Ask whether the dependency is necessary. Internal registries or proxies with approved sources may help.
Protect the build process: registry and CI tokens need minimum permissions, and build configuration changes should receive the same review as code.
Development team checklist
- Every build automatically produces a CycloneDX or SPDX SBOM.
- Each deployed version has a traceable SBOM.
- SCA covers direct and transitive dependencies.
- Deployed versions remain monitored for new vulnerabilities.
- Findings receive contextual assessment and documented decisions.
- Security updates have agreed deadlines.
- Versions are pinned and builds reproducible.
- New packages undergo name, maintainer and activity checks.
- Unmaintained components are known.
We can include dependencies and build processes alongside architecture and code in software security analysis. Start with a consultation to agree objectives and scope.
