How does CVD Portal integrate into the DevSecOps chain for my products?

CVD Portal connects to five stages of a DevSecOps chain. These stages are source control, pull request and CI checks, release pipelines, issue tracking and chat operations, and post-market advisories. Each connection records evidence for a specific Cyber Resilience Act (CRA) obligation, so the technical file grows as the pipeline runs.

Key takeaways

• CI runners push SARIF, FOSSA and SBOM results to the public API with a scoped API key.
• Webhooks and the Jira app send reports and Article 14 timers to engineering. Reporter contact details stay in CVD Portal.
• security.txt and CSAF 2.0 advisories publish the results to your customers.

Stage overview

DevSecOps stage	Direction	Mechanism in CVD Portal	CRA obligation evidenced
Source control and design	Bidirectional	MCP server and GitHub connector	Article 13(2) risk assessment and Annex VII point 3
Pull request and CI scans	Pipeline to CVD Portal	SARIF ingest and FOSSA import	Annex I Part II points (2) and (3), point (1) for FOSSA, and FprEN 40000-1-2 Clause 7.6
Release and build	Both directions	SBOM push and compliance gap checks	Annex I Part II point (1) and Annex VII point 8
Triage and remediation	CVD Portal to engineering	Jira app and webhooks	Annex I Part II points (2), (4) and (5), and Article 14
Post-release advisory	CVD Portal to customers	CSAF 2.0 VEX and /.well-known/security.txt	Annex I Part II points (4), (5) and (6), and Article 14(8)

Sources. The Articles and Annexes are in Regulation (EU) 2024/2847 on EUR-Lex. FprEN 40000-1-2 is a CEN/CENELEC draft standard and is not free to read. Clause 7.6 gives its verification requirements.

1. Source control and architecture

Connect repositories and developer AI tools before build time.

Nightly dependency graph sync. Turn on the GitHub connector in Settings, then Integrations. Use a fine-grained read-only token with the Contents and Metadata permissions. Each night at 06:30 UTC, CVD Portal pulls the repository dependency graph and updates the account SBOM. It then scans the components against OSV.dev and updates the 90-day freshness check in the control register.

IDE and agent workflows. Connect a developer agent, for example Claude Code, to /api/mcp with OAuth 2.1. Engineers and security leads can then do these tasks from the terminal.

• Generate STRIDE threats with generate_product_threats.
• Record Annex I evidence with set_annex_i_evidence.
• Draft technical file artifacts with save_artifact.
• Show open conformity gaps with get_conformity_gaps.

See MCP server.

2. Pull request and CI security testing

Send static analysis and software composition analysis results from CI runners to CVD Portal as verification evidence. See Pipeline and CI/CD connectors.

SAST and container scans (SARIF 2.1.0). Run Semgrep, CodeQL, Trivy or Grype in CI. Send the output to POST /api/v1/scan/sarif with an API key that has the sarif:write scope.

curl -fsS -X POST "https://cvdportal.com/api/v1/scan/sarif?source=github-actions&productId=$CVD_PRODUCT_ID" \
  -H "Authorization: Bearer $CVD_API_KEY" \
  -H "Content-Type: application/json" \
  --data @results.sarif

The endpoint removes duplicate findings by fingerprint for each product. It records static analysis evidence for Clause 7.6 verification.

SCA vulnerability issues (FOSSA). After fossa analyze, export the vulnerability issues. Send the JSON payload to POST /api/v1/scan/fossa with productId and a key that has the sarif:write scope.

3. Release and artifact packaging

Archive the SBOM and check release readiness each time you build a release tag or a production artifact.

Production SBOM push for each release and part. Generate a CycloneDX or SPDX JSON SBOM from the production build tree. A build SBOM excludes test-only dependencies, and the GitHub dependency graph does not. Send it to POST /api/v1/sbom with a key that has the sbom:write scope.

jq -n --rawfile content sbom.cdx.json \
  --arg productId "$CVD_PRODUCT_ID" \
  --arg part "firmware" \
  --arg releaseVersion "$RELEASE_VERSION" \
  --arg releasedAt "$(date -u +%Y-%m-%d)" \
  '{filename: "sbom.cdx.json", content: $content, productId: $productId, part: $part, releaseVersion: $releaseVersion, releasedAt: $releasedAt}' |
curl -fsS -X POST https://cvdportal.com/api/v1/sbom \
  -H "Authorization: Bearer $CVD_API_KEY" \
  -H "Content-Type: application/json" -d @-

• Send part (for example firmware, device-api or ota-service) when separate pipelines build separate components of one CRA product. CVD Portal merges up to 25 parts into one product SBOM. See SBOM registry.
• Send releaseVersion and releasedAt to archive the release SBOM. CVD Portal then correlates the components with OSV.dev and NVD or CNA records. It also reads VEX statements in the CycloneDX vulnerabilities array and checks conformance with BSI TR-03183-2.

Release gate with a stored verdict. After the SBOM push, call POST /api/v1/compliance/release-gate/runs with a key that has the gate:write scope. It checks the SBOM scan, open critical and high vulnerabilities, component support, the technical file approval, open pipeline findings and known exploited vulnerabilities. With strict: true it answers 422 when the release must not ship, and it stores each verdict with the release label and the commit. It needs the Compliance plan or higher. See Stored gate runs. On GitHub, the CRA release gate action does the pushes and the verdict in one step.

Technical file gate. During release promotion, call GET /api/v1/compliance/gaps?productId=$CVD_PRODUCT_ID with a key that has the read scope. Stop the release when readyForDocAssembly is false. The gaps array then lists each open item. Do not use GET /api/v1/compliance/status for this gate. It reads only the account verification flags and no product data. See Compliance API.

curl -fsS "https://cvdportal.com/api/v1/compliance/gaps?productId=$CVD_PRODUCT_ID" \
  -H "Authorization: Bearer $CVD_API_KEY" |
jq -e '.readyForDocAssembly' > /dev/null

4. Issue tracking, alerting and PSIRT operations

Send external vulnerability reports and supply-chain matches to engineering queues. Reporter personal data stays in CVD Portal.

Jira synchronization. Install the CVD Portal app for Jira. Give it an API key with the forge:submissions:read scope, which GET /api/v1/forge/submissions serves. Every five minutes, the app copies new and changed reports into Jira issues. Each issue gets the severity, CVSS score, steps to reproduce and affected product. Reporter contact details stay in CVD Portal.

Event webhooks. Configure outbound webhooks in Settings or with POST /api/v1/webhooks/register and the webhooks:write scope. CVD Portal formats messages for Slack, Microsoft Teams and Discord. Any other HTTPS endpoint, for example a SOAR platform or a PagerDuty relay, gets signed JSON with the X-CVD-Signature-256 header. See Webhooks. Connect these events to incident response.

Event	Meaning
submission.created	A new vulnerability report arrived.
threat_intel.match	A new CVE matches a component in your stored SBOM.
exploitation.detected	KEV, EPSS or GCVE sightings show active exploitation of a tracked CVE. Do an Article 14 review.
art14.deadline_approaching	The 24-hour early warning or the 72-hour notification under Article 14(2) is near.
art14.deadline_breached	An Article 14(2) deadline passed.
sla.breached	A report passed its resolution SLA.

Automated scanner intake. Internal DAST, pentest automation or bug bounty pipelines can send findings directly to the triage queue. Use POST /api/v1/vulnerabilities with a key that has the submissions:write scope.

5. Post-market deployment and customer distribution

Publish machine-readable advisories and the report intake address with the deployed product.

Deploy /.well-known/security.txt. Serve the generated RFC 9116 file on your production domains. It points to your CVD Portal subdomain, https://<slug>.cvdportal.com. See security.txt.

Publish CSAF 2.0 and VEX advisories. A fix ships, or you triage a component vulnerability as not_affected with CycloneDX VEX in the build pipeline or in the SBOM registry. Then publish the signed evidence pack and the CSAF 2.0 VEX document on the Trust portal. You can also export the advisory with the MCP tool generate_csaf_advisory. See CSAF export.

Last updated 9 November 2026.