04 /Security Assessment
Dependency & Supply-Chain Audit
Most applications are mostly other people’s code. This is an inventory of what you ship, a triage of the advisories filed against it, and an answer to the question no scanner can answer: is the vulnerable function ever reachable from your application? What comes back is a short list worth doing and a longer one you can defer with reasons written down.
What you get
A resolved dependency inventory
Direct and transitive packages, the versions actually installed, and the licences attached to them. Teams routinely discover they ship several hundred packages nobody has heard of, pulled in three levels down by something they chose deliberately.
Advisories triaged by reachability
Each known issue is checked against whether your code path can reach the affected function with input an attacker influences. This is the step that turns four hundred alerts into the six worth an engineer’s afternoon.
A maintenance-risk review
Packages with no release in years, a single maintainer, or a change of ownership behind a rename. None of those is a vulnerability today, and every documented supply-chain incident started as one of them.
A build-pipeline check
How dependencies are resolved and pinned, whether the lockfile is honoured in CI, which third-party actions your workflows execute, what credentials those steps can read, and how old the base image everything runs on has become.
An upgrade plan with the breaking changes named
Ordered by risk removed against effort required, with major-version jumps flagged in advance so nobody meets the migration halfway through a Friday deployment.
How it runs
- 01
Inventory
We resolve the full tree from your lockfiles across every application and service in scope, recording what is genuinely installed rather than what the manifest politely requests.
You provide: Repository access, or an export of the lockfiles and CI configuration
We produce: A dependency inventory with resolved versions and licences
- 02
Triage
Advisories are matched against those resolved versions, and then each one is read rather than counted. The database severity is a starting position; whether the vulnerable code is reachable from your entry points is the actual finding.
We produce: Reachability notes for each advisory · A ranked shortlist
- 03
Plan and hand over
We write the upgrade sequence, note what will break and where transitive pins will fight you, then set out how your team keeps the list short once we have gone. A one-off cleanup with no policy behind it regrows inside a quarter.
We produce: Remediation plan · A standing policy for updates and review
Where this stops
- Not a certified penetration test and not a signed attestation. We are neither an accredited testing body nor a notified body, so a customer wanting formally attested assurance about your software bill of materials needs a supplier who is.
- Not a full source code audit. We read your code precisely where it decides whether an advisory is reachable, and no further than that.
- Not a licence-compliance opinion. We report which licences you are shipping and where the obligations usually bite, but whether your distribution model complies with them is a question for a lawyer.
- Not a monitoring subscription. This is a point-in-time review with a plan attached, and keeping the list short afterwards is a habit for your team. We would rather leave you able to do it than bill for it monthly.
Related reading
- Application security
OWASP assessment vs penetration test: which one your requirement names
Suppliers use the two terms interchangeably. Contracts, insurers and regulators do not. How to read the clause you have been given before you buy the wrong thing.
- Application security
Broken object level authorisation: the API risk no scanner will find for you
The top entry on the OWASP API Security Top 10 returns a perfectly normal 200 to the wrong person. Why tooling cannot see it, and how the testing actually runs.
- Application security
Triaging dependency vulnerabilities: what to do with 400 open alerts
A scanner dashboard nobody opens is worse than no scanner. How to sort advisories by whether they can actually be triggered, and how to record the ones you defer.
FAQ
Dependency & Supply-Chain Audit questions we hear often
Our scanner already reports all this. Why pay for it?
Because a scanner produces a queue, not a plan. A dashboard listing four hundred open advisories against a mid-sized application reliably produces one behaviour, which is that the team stops opening it. The value here is subtraction: establishing which findings can be triggered in your application, recording why the rest were deferred, and leaving a list short enough that somebody acts on it.
How often should this be repeated?
Annually for most products, plus immediately after anything that reshapes the tree, such as a framework major version or absorbing a service from another team. Between those, automated alerts on new advisories are sufficient provided somebody owns that inbox. A quarterly review nobody reads is worth less than an annual one that gets acted upon.
Can you just do the upgrades for us?
Yes, as separate work, and it is frequently the sensible next step. It needs either a test suite worth trusting or a testing pass running alongside, because a bulk dependency bump with no verification only moves the risk from a published advisory to an unknown regression. We will tell you which of those two positions you are in before starting.
Do you produce a software bill of materials?
The inventory handed over is effectively one, covering resolved versions and licences across every application in scope. Where your customer requires a specific machine-readable format as a contractual deliverable, say so during scoping and we will produce it in that format. What we cannot do is sign it as an accredited attestation, because no such accreditation stands behind us.
Contact
Have a project in mind?
Tell us what you are building — or what keeps breaking. You will get a considered reply from an engineer, not an autoresponder.