Skip to content
Technical

Evidence your team can inspect, defend, and gate on.

QuickChain connects SBOM generation, advisory matching, static reachability, and exportable review packages. The output is built for the people who have to answer for it: where a finding came from, whether there is a runtime path, what fix data exists, and how it affects the release.

See the methodFAQ
Bring it into CI. The gate can evaluate reachable findings only.
.github/workflows/quickchain.yml
name: QuickChain
on:
  pull_request:
  push:
    branches: [main]

permissions:
  contents: read

jobs:
  quickchain:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: IronRidgeCyber/QuickChainAction@v1
        with:
          api-key: ${{ secrets.QUICKCHAIN_API_KEY }}
          project-id: ${{ vars.QUICKCHAIN_PROJECT_ID }}
          fail-on: critical
          fail-on-reachable-only: true
          wait: true
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: quickchain-results
          path: QuickChainResults/
Static reachability

One finding is work. One is documented.

QuickChain works out which vulnerable functions your application can actually reach at runtime, and gives every finding a defensible disposition. The two below came from the same scan.

Reachable
POST /api/orders
HTTP entry point
parseOrder(req.body)
app code
authService.verify(token)
app code
jsonwebtoken.verify()
CVE-2022-23529 · critical

A runtime call path runs from the route to the vulnerable function. QuickChain keeps this finding in the queue with the evidence attached.

No execution path
crypto-js @ 3.3.0
CVE-2023-46233 · critical
imported only by a build-time cookie helper.
no call path from any entry point.
openvex: status = not_affected
justification: vulnerable_code_not_in_execute_path

The suppression is deterministic and carries its own justification, so an assessor can see why the finding was set aside.

Two critical findings from the same scan. One is work, one is documented.

Dependency manifests

The transitive tree is built from the manifests and lockfiles in the repo.

package.jsonpackage-lock.jsonrequirements.txtpyproject.tomlPipfilego.modCargo.tomlbuild.gradlebuild.gradle.ktspom.xmlcomposer.json

Language coverage

Runtime reachability analysis is deepest on JavaScript, TypeScript, and Python. Inventory coverage extends across the rest.

JavaScriptTypeScriptPythonJavaGoRubyPHPCC++C#KotlinSwiftRust
Evidence formats

Standards in, standards out

The same scan produces machine-readable evidence in the formats your reviewers already parse.

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "author": "QuickChain",
  "statements": [
    {
      "vulnerability": { "name": "CVE-2023-46233" },
      "products": [
        { "@id": "pkg:npm/crypto-js@3.3.0" }
      ],
      "status": "not_affected",
      "justification": "vulnerable_code_not_in_execute_path",
      "impact_statement": "No call path from an HTTP entry point reaches the affected function."
    }
  ]
}
  • CycloneDX JSON SBOM
  • SPDX SBOM
  • OpenVEX JSON
  • OSCAL assessment results
  • POA&M workbook (XLSX)
  • Risk assessment memo (DOCX)
  • CSV extracts
  • ZIP package with manifest and SHA-256 hashes
QuickChain software inventory view showing in-use components with their dependency paths and runtime evidence.
Every in-use component keeps the evidence behind it: the dependency path and the runtime basis.
Technical FAQ

Questions engineers ask

Run a scan on a repository you know

See the business case