Transparency about process is part of what makes a consulting engagement trustworthy. This page describes exactly what we do, in what order, and why.
Every engagement begins with a scoping conversation. This is not a sales call. It is a technical conversation.
We ask about your technology stack, your package manager setup, your current tooling for dependency management, and what integrations are active in your production environment. We also ask what is already being reviewed internally and what is not, because the goal is to complement what exists, not duplicate it.
From that conversation, we define the scope of the engagement in writing: which repositories are in scope, which runtime environments, which integration categories. That written scope becomes the reference point for everything that follows.
We are given read-only access to the repositories in scope. No write permissions are requested. No production system access is needed for this phase. Our tooling traverses the dependency manifests — package.json, requirements.txt, pom.xml, go.mod, Gemfile, or whichever formats apply — and constructs a complete graph of all declared and resolved dependencies.
Each package in the inventory is evaluated against public vulnerability databases including the NVD, OSV, and ecosystem-specific advisories. We also assess maintenance health: when was the package last updated, does it have an active maintainer, how many open issues relate to security, and what is the release cadence trend. Packages that appear healthy by CVE count alone can still present significant risk if they are effectively unmaintained.
For integrations in scope, we examine the implementation code to understand authentication patterns, data transmission practices, and error handling. We document what data categories are sent to each external service, whether those transmissions are encrypted and authenticated correctly, and whether the integration has graceful fallback behavior. We also look at the vendor's own security posture — published security documentation, incident history, and current SLA commitments.
Raw findings are not presented in discovery order. They are ranked. The ranking uses two axes: potential impact to the system or its users, and remediation effort required. This produces a matrix that engineering teams can use to sequence their work. High-impact, low-effort items surface first. High-impact, high-effort items are flagged for planning. Lower-impact items are documented without urgency.
Two documents are produced: a technical report with full finding details, evidence, and remediation guidance; and an executive summary that presents the overall supply chain posture without technical depth. A handoff session is conducted with both engineering and stakeholder audiences where needed. The SBOM artifact is delivered separately in machine-readable format for integration with your own tooling.
All analysis is conducted with read-only repository access. We never request permission to modify code or configuration.
Dependency analysis operates on manifest files and source code. Runtime environments are not accessed during audit work.
We do not perform active exploitation, vulnerability probing, or network scanning. Our scope is the supply chain, not the attack surface.
Analysis tools run on our infrastructure. Nothing is deployed to client systems as part of the engagement.
If you have specific questions about how we handle data access, confidentiality, or any aspect of the process, we are glad to discuss them before any engagement begins.