Software Composition Analysis (SCA) Services

A penetration test attacks the code you wrote; Software Composition Analysis examines the code you inherited. The distinction matters because the two surface different problems. Our VAPT work is manual and exploit-driven: an engineer probes your logic, authentication and data handling, and proves each finding with a working proof of concept. That engineer will not read the changelog of every transitive package sitting four levels below your lockfile, and a vulnerable library is frequently invisible from the outside until somebody publishes a route into it. SCA works the other way round, from the inventory inwards. We enumerate direct and transitive dependencies, map each version against CVE, NVD and OSV data, and then triage by reachability so the list reflects your exposure rather than your package count. Teams shipping modern applications generally want both, because they answer different questions when a customer or an auditor asks. Our VAPT practice page sets out how the testing side runs.

Those are transitive dependencies: packages pulled in by the packages you chose, often several levels deep, and in most codebases they outnumber the direct ones heavily. They are still yours to answer for, because your build ships them. What changes is how we treat them. Phase three of the engagement is reachability and exploitability triage, where we trace call paths from your own code into the affected function and ask whether the vulnerable routine is ever actually invoked. A high-severity advisory in a parser you never call, or in a package present only in your test and build tooling, is not the same risk as one sitting on a live request path, which is why we separate runtime dependencies from build-and-test-only ones. The named handover is a reachability-ranked exposure list, so your engineers receive an ordered queue to work through rather than a dashboard count to argue with.

Because a licence obligation can hold up a release as firmly as a vulnerability can, and it usually surfaces later and more expensively. Phase four resolves the licence of every component in the inventory, transitives included, which is where the surprises tend to live: a permissively licensed package you chose can pull in a copyleft one you did not. We check what we find against your policy, highlight copyleft obligations that bite when software is distributed rather than hosted, flag conflicts, and list components whose licence metadata is missing or ambiguous so that somebody can make a decision about them. The output is a licence risk register you can hand to whoever owns legal review. Be clear on the boundary: we are security engineers, not your counsel, so we identify and explain each obligation and its context, while the decision to accept, replace or comply stays with you.

You receive a standards-based SBOM in CycloneDX or SPDX format, generated in phase one and reconciled against what you actually ship rather than what your manifest claims. Those two formats are what procurement teams, auditors and platform partners tend to ask for, so the file drops into their tooling without translation. Be clear about what an SBOM is and is not. It is an inventory, not an assurance: it records which components are present, not whether they are safe or reachable, which is why the mapped vulnerability inventory and the reachability-ranked exposure list travel alongside it. Reviewers commonly ask for that second layer once they have the first. We also automate SBOM generation on every release as part of the pipeline work, so the copy you send a customer next quarter describes the build you shipped rather than one from the month we finished.

New advisories land against code you have not touched, so a point-in-time scan begins ageing the day it is delivered. That is why the engagement ends in continuous monitoring rather than in a report. Phase six wires the scan into your pipeline, sets the policy for what blocks a build and what merely warns, automates SBOM generation on every release, and routes new alerts to the team that owns the service, so ordinary drift is caught on the build instead of months later. A fuller human pass earns its place when the dependency graph changes materially, such as a major framework upgrade, a new service or an acquired codebase, or ahead of an audit or customer review. Be clear on the limit of the pipeline gate: it re-checks an inventory it already knows, so a fresh reachability triage and licence review is scoped as its own piece of work.