Dependency and CI/CD security review

How do you tell whether a dependency vulnerability is actually exploitable?

Each advisory is verified against the exact version pinned in your manifests and lockfiles, not against a version range, so an advisory that does not apply to your pinned version is not reported as a risk. Findings are then ordered by real exposure rather than by raw CVSS score, and anything exploitable is reported first and privately through your security channel. The review is read-only and reports what it finds; it cannot promise that no other vulnerability exists.

What does a CI/CD security review include?

The review checks your CI and CD workflow permissions, tokens and third-party actions with OpenSSF Scorecard, looks at manifests and lockfiles for internal package names that a public registry could shadow (dependency confusion), and can add an optional EU Cyber Resilience Act readiness check covering the security policy, security.txt, SBOM and the vulnerability-reporting workflow. It is read-only: you choose the repositories and nothing is pushed to your code.

Who it is for

• Teams shipping software with third-party dependencies in Java, Go, JavaScript, Python or similar ecosystems.
• Companies that need to show, before an audit or a customer review, that their dependencies and pipelines were checked.
• Open-source maintainers and vendors preparing for the EU Cyber Resilience Act.

What the review covers

• Known vulnerabilities. Production dependencies checked against OSV, with each advisory verified against the exact version pinned in your manifests and lockfiles — not a version-range guess.
• Dependency-confusion risks. Manifests and lockfiles reviewed for internal package names that a public registry could shadow.
• CI/CD workflow permissions. Workflow tokens, third-party actions and supply-chain settings reviewed with OpenSSF Scorecard.
• Optional CRA readiness. Security policy, security.txt, SBOM and the vulnerability-reporting workflow (technical, not legal advice).

What you receive

• A written report: each finding with its source and, when one exists, the version that fixes it.
• Findings ordered by real exposure, not by raw CVSS score.
• Anything exploitable reported first, privately, through your security channel.
• One round of follow-up questions by email after delivery.

How it works

• Read-only. You choose the repositories; nothing is pushed to your code.
• Within 2 business days you receive the scope in writing: repositories, whether CRA readiness is included, delivery date and price.
• 50% is paid when the work starts and 50% on delivery.
• The work is asynchronous: email and the written report. A call is available if you prefer one.

Price

• USD 4,800, fixed, for one repository and its CI/CD workflows, delivered within 5 business days.
• USD 12,000, fixed, for up to 5 repositories of the same system, delivered within 10 business days.
• + USD 1,500 for the optional EU CRA readiness check, adding 2 business days to either level.
• Paid by international bank transfer in USD, against an invoice.

Terms in short

• The review is read-only and reports what it finds; it cannot promise that no other vulnerability exists.
• Your code and your data stay confidential. Signing your NDA is fine.
• CRA readiness is a technical check, not legal advice. Liability is limited to the price paid.

Track record

• Vulnerable dependencies reported to open-source maintainers and fixed after the report — for example reactive-commons-go#5, from 10 advisories to 0, fixed by the maintainers 3 days later.
• Every advisory is verified against the exact pinned version in OSV before it is listed: see the open-source security reports.

Start

• Email contact@gaphunterlabs.com with “Dependency security review” in the subject, or use the contact page. Tell me the repositories and whether you need the CRA readiness check.