Skip to content

Security: Vulnerability Management

This page documents how the library implements the monitoring and mitigation controls from §4.3 and §4.4 of the ENISA Technical Advisory for Secure Use of Package Managers.

Automated Scanning

Partially aligns with ENISA TA §4.3.1 (SBOM-driven Monitoring) and §4.3.2 (Automated Scanning in CI/CD).

This repository does not produce or consume container image SBOMs, so §4.3.1 is a gap for the workflow definitions themselves. Callers should implement SBOM generation/consumption in their image release pipelines. This project relies on GitHub Security Advisories (GHSA) and Dependabot for workflow dependency security.

SBOM-driven Monitoring

This library ships workflows, not direct container images. Callers that run release-container.yaml produce container images and may generate CycloneDX SBOMs and cosign attestations as part of their image release pipeline. The workflow is designed so that callers can consume SBOMs for vulnerability correlation and compliance.

Action Dependencies — Dependabot

Dependabot monitors all uses: references in .github/workflows/ and opens pull requests when new versions with security fixes are available. It covers the GitHub Advisory Database, which aggregates CVEs from multiple upstream sources.

OSV-Scanner integration — tracked gap

Trivy and Dependabot cover container images in caller pipelines and direct action version updates. Automated scanning of the full action dependency graph (transitive dependencies inside action JavaScript/Docker images) using OSV-Scanner is tracked as a future improvement.

Advisory Monitoring

Implements ENISA TA §4.3.3 (Track CVEs/Advisories), §4.3.5 (Set Alerts).

The following advisory sources are checked as part of the quarterly security review:

Source Scope How to check
GitHub Advisory Database Actions + container OS packages Dependabot alerts in repository Security tab
ENISA EU Vulnerability Database (EUVD) EU-specific CVE aggregation Manual review quarterly
OSV.dev Open source packages across ecosystems Manual osv-scanner run on lockfiles
CISA KEV Catalog Known actively exploited vulnerabilities Manual review quarterly

For immediate alerts, GitHub Dependabot security alerts are enabled in repository settings. Maintainers with security-events: read access will receive email notifications for new HIGH/CRITICAL findings.

EUVD/CSAF automated ingestion — tracked gap

Automated ingestion of ENISA EUVD or CSAF (Common Security Advisory Framework) machine-readable feeds is tracked as a future improvement for fully automated advisory correlation.

Assessment

Implements ENISA TA §4.4.1 (Assess).

When a vulnerability is identified, assess it using the following metrics before deciding on priority and mitigation:

Metric Description Source
CVSS Base severity score (0–10) and attack vector NVD / advisory
KEV Is this CVE in CISA's Known Exploited Vulnerabilities catalog? cisa.gov/kev
Reachability Is the vulnerable code path actually reachable in our use? Manual review; CodeQL if available

Assessment steps:

  1. Retrieve the CVSS score and vector from the NVD or the GitHub advisory.
  2. Check whether the CVE is in the CISA KEV catalog.
  3. Determine reachability: does this library's usage invoke the vulnerable code path? If the vulnerable function is never called, document this in the issue.

Prioritisation

Implements ENISA TA §4.4.2 (Prioritise).

Use the following thresholds to determine response speed. These are the same thresholds that callers enforce in the container image release workflow (e.g. release-container.yaml with Trivy gates):

Priority Criteria Target Response
Critical CVSS ≥ 9.0 or in CISA KEV catalog Fix or mitigate within 48 hours
High CVSS 7.0–8.9 Fix or mitigate within 7 days
Medium CVSS 4.0–6.9 Address in next planned release cycle
Low CVSS < 4.0, not reachable Track; address opportunistically

If reachability analysis confirms the vulnerable code path is not exercised by this library, the effective priority may be reduced one level and documented as such in the tracking issue and notification documentation.

Mitigation Steps

Implements ENISA TA §4.4.3 (Mitigate).

For actions (third-party uses: references)

  1. Update the SHA pin — Open a PR updating the uses: SHA to the patched version. If Dependabot has already opened such a PR, expedite its review.
  2. Assess impact while updating — If the new version introduces breaking changes, document the migration path in the PR.
  3. Temporary mitigation — If no patched version is available, evaluate whether the workflow can be temporarily disabled or replaced with an alternative action.
  4. Remove if irreparable — If the action is abandoned and the vulnerability is critical, remove it and implement the step inline or replace with a maintained alternative.

Emergency response

For Critical findings (CVSS ≥ 9.0 or KEV):

  1. If the vulnerability is in an action currently used in a running workflow, consider temporarily disabling the workflow until the fix is in place.
  2. Notify dependent repositories by opening a GitHub Security Advisory draft in this repository.
  3. Fast-track a patch release following the normal PR → semantic-release flow with a fix: or BREAKING CHANGE: commit prefix as appropriate.

Notification

Implements ENISA TA §4.4.4 (Document & Notify).

Notification path for fixed vulnerabilities:

  1. Release notes — Include the CVE ID and affected component in the release notes generated by go-semantic-release. Use fix: or security: commit prefix.
  2. GitHub Security Advisory — For Critical/High vulnerabilities that affect callers, publish a GitHub Security Advisory in this repository. This triggers Dependabot alerts in all caller repositories that depend on this library.
  3. Tracking issue — Keep a GitHub issue open for the duration of the vulnerability lifecycle. Label it security and link it to the relevant Dependabot alert or advisory.

When a vulnerability is fixed in this library:

  1. Release notes — Include the CVE ID and affected component in the release notes generated by go-semantic-release. Use fix: or security: commit prefix.
  2. GitHub Security Advisory — For Critical/High vulnerabilities that affect downstream callers, publish a GitHub Security Advisory in this repository. This triggers Dependabot alerts in all downstream repositories that depend on this library.
  3. Tracking issue — Keep a GitHub issue open for the duration of the vulnerability lifecycle. Label it security and link it to the relevant Dependabot alert or advisory.

Attribution

Controls in this page are derived from the ENISA Technical Advisory for Secure Use of Package Managers, v1.1, March 2026. Licensed under CC BY 4.0.