Know which library is vulnerable,
and whether the service ever loads it.
Datadog Software Composition Analysis lists every open source library in the repository and every one the running service actually loads, then scores each advisory by whether it is reachable, exposed and being exploited. We enable it on the repositories and services that matter and set the licence rules to a decision you have written down. Then we operate it every month, so the advisory that lands on a Thursday has an owner by Friday.
Quick facts
Related
- Code Security, the group this belongs to
- Vulnerability Management, the same question asked of hosts, containers and images
- Static Code Analysis, rules on the code you wrote rather than the code you imported
The answer to "are we affected" in minutes, with the services named
An advisory lands. The question from the board is simple: are we exposed, where, and how badly. Without an inventory the answer is a day of grepping lockfiles and a guess about what is deployed. With one, it is a search in the CVE Explorer and a list of services, each with its owner.
Two inventories, joined. The static scan reads lockfiles and manifests on every commit that changes them. The runtime scan reads what the tracer sees loaded in the service. A dependency declared but never loaded shows up in the first list and not the second, which is the reconciliation we run.
A severity score that reflects your estate. Datadog adjusts the CVSS base score for reachability, whether the service is in production, observed attack activity, exploit availability and EPSS. The top of the list is the list to work.
Licences and end-of-life libraries, in the same view. Every library carries its licence and its OpenSSF risk. A pull request that introduces a licence the organisation has rejected can be failed by a PR Gate before it merges.
An SBOM that is produced, not maintained. The Library Inventory exports CycloneDX 1.6 or SPDX 2.3 covering static and runtime libraries. Pull request checks report only the vulnerabilities a change introduces, and Jira or ServiceNow tickets carry the repository findings to the owner.
A repository with no lockfile, a service with no tracer, and a licence rule with no policy behind it
How it bills. Static Software Composition Analysis is part of Code Security and is billed per committer, per month. Datadog counts a committer as an active Git author, identified by email address, who commits at least three times in the month. Runtime detection is billed per host when bought on its own, and runs on any host with the Datadog Agent when it comes in a Code Security bundle. It runs inside the Datadog SDK, so the services it covers need the Agent and the SDK sending web traces. It does not need an APM subscription, although some APM intake for security traces appears on the bill. Datadog publishes the meters and rates. The lever is which repositories are enabled and which services carry runtime detection. A mirror of a vendor's repository adds findings that are not yours to fix.
The configuration traps. A repository with a manifest and no lockfile, so the scan resolves version ranges rather than the versions actually installed and the findings do not match the build. Runtime detection enabled on half the services, so the inventory says a library is unused when the service that loads it simply has no tracer. Licence rules switched on with the default list, so a copyleft finding reaches a developer who has no idea whether the organisation accepts it. The SBOM exported once for the questionnaire and attached to every questionnaire after it. Findings muted for a transitive dependency because the fix is in an upstream package, with no date to check whether upstream has fixed it.
Field noteThe most common gap we see is that the static scan is on and runtime detection is not. The inventory is a list of everything ever declared. Without the runtime half, the score cannot tell a loaded library from a forgotten one, and the list stays too long to work.
Field noteThe pattern we keep finding on advisory day is that the service list is right and the owner list is not. The inventory names the service. The team that owned it was reorganised. The advisory waits for the organisation chart.
Field noteLicence findings are the ones most often closed as not applicable by the developer who received them. The tool was right. The decision about which licences are acceptable had never been written down, so there was nothing to be right against.
Field noteA fix pull request that bumps a major version is the one that stays open longest. The vulnerability is real, the upgrade breaks the build, and the finding is muted until the next advisory in the same library reopens the question.
Lockfiles first. Tracers second. A licence list before the licence rule.
Software Composition Analysis is delivered inside the Code Security Accelerator, four weeks, fixed scope. If the services have no tracer yet, APM comes first through LaunchPad or the Infrastructure Observability Accelerator, because runtime detection has nothing to read without it.
- Agree the repository and service list. Which repositories get static scanning, which services get runtime detection, and who owns each. A service nobody owns is assigned an owner before it is enabled.
- Fix the inputs. Every enabled repository has a committed lockfile for its package manager. Every service in scope runs a tracer version that supports runtime detection. Both checked before the first scan, not after.
- Enable static scanning and let the inventory fill. Hosted scanning or a CI job on push, one or the other. The Library Inventory and the CVE Explorer are reviewed with you once the first full pass has run.
- Enable runtime detection and reconcile. The runtime list is compared to the static list per service. Declared-but-unloaded libraries are noted. Loaded-but-undeclared ones are investigated, because they are usually a build image problem.
- Set the licence list and the gates. The accepted licence list is written by your leadership, not by us. We configure the rule to it, set PR checks informational for a fortnight, then make the gate blocking for the severities agreed.
- Hand over, in writing. Repository and service scope, tracer versions, the licence list and its sign-off, and the gates in force. Muted findings with reasons and dates, the SBOM export configuration, and the open findings on the day we finished.
Access is admin on the Datadog organisation, the Datadog app on GitHub, GitLab or Azure DevOps with read access to the repositories in scope, and the deployment tooling that ships tracer configuration. We do not commit to your repositories. Fix pull requests are opened for your developers to review and merge.
An inventory is only true on the day it was reconciled
A new service ships without a tracer. A package manager is swapped and the lockfile format changes. An advisory reclassifies a library everybody had accepted. Managed Observability is the monthly service that keeps the two inventories matching the code that is deployed now.
Every month, the new advisories are worked. New findings are read against the services that load the library and the score Datadog assigned. The critical and reachable ones go to the owner with the fix pull request attached. The rest are recorded with a reason.
Coverage follows the deployments. New repositories are enabled. New services get runtime detection when they get a tracer. Services that were retired leave the inventory, so the SBOM does not list software you no longer run.
Mutes carry a date. A finding muted because the fix is upstream is checked each month for an upstream release. A finding muted because the library is unloaded is reopened if runtime detection later sees it loaded.
The malicious package is raised that day. Datadog reports a malicious package within hours of it being identified. When one appears in your inventory, the owning team is told the same day with the service, the version and the removal steps.
We operate the stack. You own the product.
We are not a security company. We are a managed runtime operator. We run the dependency scanning inside your Datadog and reconcile what it finds against what the services load. We fix what sits in the runtime we operate and route the rest to the team that owns the code, with the evidence attached. We operate and evidence the runtime controls that support your compliance obligations. The licence policy, the upgrade decisions and the code stay yours.
Datadog is our proof, not our headline. Datadog certified one managed provider globally. We are it. The Powered by Datadog accreditation means Datadog's own engineers reviewed how we instrument, alert, respond and report. We are also a Datadog Advanced Partner, ISO 27001 certified and Cyber Essentials Plus certified, with offices in Cardiff, London and Dublin.
Datadog Software Composition Analysis, answered plainly
What is the difference between static and runtime Software Composition Analysis in Datadog?
Static detection reads the lockfiles and manifests in a repository and lists every dependency declared there, including the transitive ones. Its findings belong to the repository. Runtime detection uses the APM tracer to list the libraries a service actually loads while it runs. Its findings belong to the service. A library can appear in the first list and never in the second. The severity score then adjusts for whether the vulnerable function is referenced in code, production context, attack activity, exploit availability and EPSS.
How is Datadog Software Composition Analysis billed?
Static Software Composition Analysis is part of Code Security, billed per committer, per month. Datadog counts a committer as an active Git author, identified by email address, who commits at least three times in the month. Runtime detection is billed per host when bought on its own, and runs on any host with the Datadog Agent when it comes in a Code Security bundle. Either way the services it covers need the Datadog SDK sending web traces, not an APM subscription. Datadog publishes the current meters and rates. We do not publish prices. We do decide, with you, which repositories are enabled and which services carry runtime detection.
Can Datadog export an SBOM?
Yes. The Library Inventory exports a software bill of materials covering both static and runtime libraries, in CycloneDX 1.6 or SPDX 2.3 format. We set the export up once, record which repositories and services it covers, and keep that scope current, so the file a customer asks for in a questionnaire is produced from the inventory as it is that day rather than from a spreadsheet somebody last updated for the previous questionnaire.
Does Datadog Software Composition Analysis check licences?
It does. Every detected library carries its licence in the inventory, and PR Gates can fail a pull request that introduces a licence the organisation does not accept. The tool cannot decide which licences those are. That is a decision for your legal or engineering leadership, written down before the rule is enabled. We configure the rule to that decision, route the findings to the owning team, and keep the record of what was accepted and when.
What does Critical Cloud do with Software Composition Analysis every month?
Managed Observability reviews the new library findings against the services that load them and works the critical ones with the owning team. It confirms that newly deployed services carry runtime detection and that new repositories are enabled. It re-confirms or reopens muted findings, keeps the SBOM scope current, and reports what was found, fixed and routed. A malicious package reported by Datadog is raised to the owner the same day.
- Datadog products: every product, and how we implement and run each one
- Code Security: the group, and how findings reach the developer
- Vulnerability Management: the same exposure question for hosts, containers and images
- Code Security Accelerator: repositories, scanners, rules and gates, in four weeks
Every library known. Every advisory with an owner by Friday.
Tell us which package managers you use and which services take external traffic. We will show you what the inventory would say today, which advisories are reachable, and what it takes to keep it true.