Practices
Dependency Scanning
Checking the open-source libraries, container images and operating system packages a system uses against databases of known vulnerabilities, so the team learns quickly when something it ships needs an update.
Part of Quality & Security
Dependency scanning, also called software composition analysis (SCA), lists the third-party packages an application includes and matches each version against public databases of known vulnerabilities.
Why it is needed
Much of a typical application's code comes from open-source packages, often including hundreds of transitive dependencies that nobody on the team chose. When a vulnerability in one of them is published, the advisory often comes with a fixed version, and attackers then look for systems that have not applied it. Scanning shows which of your systems use the affected version. Container base images and their operating system packages need the same scanning.
What it does not catch
A scanner only finds vulnerabilities already in its databases. It will not find a zero-day, which is exploited before any advisory exists, and on its own it misses most malicious packages. Reviewing new dependencies and pinning versions in a lock file reduce those risks.
How we use it
Scans run on every build and on a schedule, since new advisories appear for code that has not changed. We agree a patch window per severity and name someone to read the results. A software bill of materials (SBOM) for each release answers "are we affected, and where" from a list. Findings are triaged by severity and by whether the vulnerable code path is reachable.