A Software Bill of Materials (SBOM) shows the components inside an application and where they came from. But generating an SBOM is only the beginning. Its real value comes from using that information to reduce risk and respond when something goes wrong.
During DCI and JFrog’s recent webinar, From Inventory to Action: Putting SBOMs to Work, JFrog Field CISO Paul Davis and Cybersecurity/AI Specialist Lester Wong discussed how organizations can move from simply creating SBOMs to using them as practical security tools.
Here are three key lessons from the discussion.
1. Federal expectations are becoming clearer
A recent Treasury Board Security Policy Implementation Notice directs federal departments to maintain SBOMs for department-developed software that supports critical services.
The scope is important: this does not mean every government application requires an SBOM. However, it does show that software component visibility is becoming a more formal part of how departments manage risk for critical services.
Organizations should start by identifying which applications fall within scope and whether they can produce accurate, current information about the components those applications contain.
2. An SBOM should be a living source of security data
Creating an SBOM and storing it as a document provides limited value. Software changes, new vulnerabilities are disclosed and previously trusted components can become risky.
SBOM data should be current, searchable and connected to vulnerability monitoring. When a new vulnerability is announced, teams should be able to quickly determine:
- Whether the affected component is being used
- Which applications contain it
- Which versions are affected
- Where remediation should be prioritized
This allows organizations to answer “Are we affected?” using reliable component data instead of emails, spreadsheets and manual checks.
3. AI is expanding the software supply-chain risk surface
AI-assisted development can increase the speed at which code, packages and dependencies enter an organization. AI models and datasets are also becoming dependencies that organizations will need to track and assess.
This makes visibility more important—not less. Organizations need controls that can identify risky or untrusted components before they enter a software build and continue monitoring them after deployment.
SBOMs provide an important foundation for that work. The next challenge is extending the same visibility and accountability across AI-powered applications, models, data and infrastructure.
Continue the conversation on November 18
DCI’s free AI Security Executive Session will bring government and technology leaders from F5, HPE, and JFrog together at the Canadian War Museum in Ottawa to explore three questions:
- What’s at stake?
- Where are the risks?
- What can organizations do next?
