The situation
A customer asks whether a named vulnerable library is in a deployed release.
Dependency Scanning & SBOM
Dependency analysis identifies the external components used by software. A software bill of materials records that composition so teams can investigate exposure and respond when component risks change.
- Map component inputs
- Generate usable records
- Connect inventory to action
Is this right for you?
When this is the right work.
You cannot reliably identify which releases contain a vulnerable component or provide a component inventory to a customer.
The first conversation establishes the environment, the constraint and who will accept the result. We agree a bounded starting point before expanding the engagement.
Scope
What DotConn delivers.
- 01
Map component inputs
Review package manifests, lockfiles, build artifacts and transitive dependencies.
- 02
Generate usable records
Produce an SBOM in an agreed machine-readable format and tie it to a release.
- 03
Connect inventory to action
Define vulnerability triage, update ownership and the response when a relevant advisory appears.
Deliverables
What you receive.
Acceptance criteria identify the checks, records and handover needed for the agreed scope.
- Release-linked component inventory
- Dependency checks and SBOM generation
- Risk triage and update process
In practice
A practical example.
Our approach
We establish a release-linked inventory and a process for checking exposure and updating affected components.
The useful result
The team can answer from a maintained record rather than reconstruct the build manually.
Responsibility
Agree the responsibility.
DotConn
Assesses and delivers the technical work in the agreed scope, with reviewable changes and handover. Continuing operation requires a separately defined managed-service scope.
Your team
Provides authorized access, business priorities and accountable decision-makers; approves policy choices and accepts the agreed result.
Set this boundary early
An SBOM is an inventory, not a security guarantee. Completeness, generation context and ongoing analysis must be agreed.
FAQ
Questions worth resolving.
Technical reading
Is dependency scanning enough without an SBOM?
Scanning identifies findings at a point in time. A release-linked inventory supports later investigation and traceability; the two serve related but different needs.
Pricing, timing and how to prepare are covered in working with DotConn.
Connected work
Services that work alongside this.
Container Image Security
Container security work reviews the software and configuration packaged in an image, alongside how that image is built and promoted into use.
ExploreStatic Application Security Testing
SAST analyzes application source or compiled code for potential security weaknesses without exercising the running service. Its value depends on language coverage, rule quality and useful feedback to developers.
ExploreAudit-Readiness Controls & Evidence
Audit-readiness engineering turns agreed control requirements into implemented technical measures and reviewable evidence. It helps teams explain how a control operates and who is responsible for it.
ExploreApplication & Code Security
Application security combines complementary checks of source code, dependencies, containers and running behavior. The goal is an actionable view of risk and a way to verify remediation.
Explore