Security¶
This section documents how the reusable workflows in this library implement the security controls recommended by the ENISA Technical Advisory for Secure Use of Package Managers (v1.1, March 2026, CC BY 4.0).
Although the ENISA advisory focuses on traditional package managers (npm, pip, Maven, etc.), its controls map directly to GitHub Actions workflows: every referenced third-party action is a package, and the GitHub Marketplace / repository reference system is the registry. The same risks apply — dependency confusion, supply chain injection, compromised maintainers — and the same mitigations work.
For Project Potos this mapping has extra weight: this library is the single point for all external CI/CD dependencies. Every potos repository calls these workflows instead of maintaining its own, so third-party actions are selected, pinned, audited, and updated in exactly one place.
Threat Model¶
| ENISA Risk | GitHub Actions Equivalent |
|---|---|
| Insertion of malicious packages | A third-party action is replaced or injected with malicious code in a new commit |
| Compromised legitimate package | An action maintainer's account is hijacked and a backdoored version is published |
| Typosquatting | An action with a name similar to a trusted one (e.g. actons/checkout) is published |
| Namespace / Dependency Confusion | An action published in a public namespace shadows an intended private one |
| Discontinued / unmaintained packages | An abandoned action receives no security fixes |
Controls Compliance Matrix¶
All controls from ENISA TA §4 are mapped below. Status: ✅ Implemented · ⚠️ Partial · ❌ Gap · N/A Not applicable
§4.1 Package Selection¶
| Control | Description | Status | Reference |
|---|---|---|---|
| 4.1.1 Trusted Source | Use official registries; prefer provenance metadata | ✅ | SHA pins enforce exact commit; org-level allowed_actions allowlist restricts sources; Renovate keeps pins current |
| 4.1.2 Known Vulnerabilities | Check vulnerability databases before adopting a dependency | ⚠️ | Dependabot alerts exist; pre-adoption checks are part of the selection criteria but not yet automated (see radiorabe/actions#194) |
| 4.1.3 Signing & Integrity | Use cryptographic signing to verify integrity | ✅ | SHA pinning is cryptographic integrity for actions; keyless build-provenance attestation for containers |
| 4.1.4 Maintainer Reputation | Select packages from reputable, verified maintainers | ⚠️ | Criteria documented in Supply Chain; no automated checks |
| 4.1.5 Popularity & Maintenance | Community adoption, recent activity, commit history | ⚠️ | Criteria documented in Supply Chain |
| 4.1.6 Secure Practices | Evaluate the action's own security posture | ⚠️ | Criteria documented in Supply Chain; this library's own workflows are zizmor-pedantic clean |
§4.2 Package Integration¶
| Control | Description | Status | Reference |
|---|---|---|---|
| 4.2.1 SBOM Creation | Generate a Software Bill of Materials | ❌ | This repository does not generate a SBOM for the workflows and their action dependencies |
| 4.2.2 Vulnerability Checks | Enforce security gates in CI/CD | ⚠️ | zizmor (pedantic) and actionlint gate every PR; no CVE scanning gate for container images yet |
| 4.2.3 Integrity Enforcement | Enforce hash or lockfile verification | ✅ | All actions pinned to a full commit SHA (@<sha> # vN.N.N) |
| 4.2.4 Source Enforcement | Restrict to trusted registries; validate source URLs | ✅ | SHA pinning prevents substitution; org-level allowed_actions per repository is managed centrally via OpenTofu |
| 4.2.5 Installation Script Prevention | Disable/restrict scripts during installation | N/A | GitHub Actions has no equivalent install-script mechanism |
| 4.2.6 Pinning Versions | Fix dependency versions; use lockfiles | ✅ | Every third-party reference is pinned to a commit SHA; internal references are relative and resolve at the consumer's pin |
§4.3 Package Monitoring¶
| Control | Description | Status | Reference |
|---|---|---|---|
| 4.3.1 SBOM-driven Monitoring | Leverage SBOM data to automate vulnerability correlation | ❌ | This repo does not create/consume SBOMs |
| 4.3.2 Automated Scanning in CI/CD | Continuously scan dependencies | ⚠️ | zizmor and actionlint run on every PR; transitive action dependencies are not scanned — see Vulnerability Management |
| 4.3.3 Track CVEs / Advisories | Monitor EUVD, OSV.dev, GitHub Advisories | ⚠️ | Renovate covers the GitHub Advisory Database and OSV.dev; manual EUVD monitoring documented in Vulnerability Management |
| 4.3.4 Monitor Outdated Versions | Check for newer versions | ✅ | Renovate opens PRs for outdated SHA pins (7-day cooldown against fresh releases) |
| 4.3.5 Set Alerts | Alerts for new CVEs, deprecated releases, maintainer changes | ⚠️ | Renovate covers CVE/version alerts; no automated maintainer-change detection |
§4.4 Vulnerability Mitigation¶
| Control | Description | Status | Reference |
|---|---|---|---|
| 4.4.1 Assess | CVSS, EPSS, KEV metrics; reachability analysis | ⚠️ | Process documented in Vulnerability Management; no automated reachability tool yet |
| 4.4.2 Prioritise | Risk thresholds (CVSS ≥ 7.0, EPSS, KEV) | ✅ | Thresholds documented in Vulnerability Management |
| 4.4.3 Mitigate | Upgrade, temporary controls, removal | ✅ | Steps documented in Vulnerability Management |
| 4.4.4 Document & Notify | Release notes, GHSA advisories, notify stakeholders | ⚠️ | Process documented in Vulnerability Management; full automation not yet in place |
Library-Specific Controls¶
Beyond the ENISA mapping, this library enforces controls specific to its role as the single pipeline source for the potos organization:
| Control | Implementation |
|---|---|
| Version consistency for internal reuse | Sibling workflows are referenced relatively and resolve at the same commit as the consumer's pin |
| Least-privilege permissions | permissions: {} at the workflow level, minimum per-job grants, every write grant commented; see Permissions |
| Injection hardening | All inputs.* values reach run: blocks via env: variables, to prevent template injection |
| Side-effect gating | Push/publish/deploy/attest steps are run on non-PR events only |
| Org-level enforcement | allowed_actions per repository and required status checks are managed centrally via OpenTofu |
Sections¶
- Supply Chain Security — action selection, SHA pinning, provenance, SBOM (§4.1, §4.2)
- Vulnerability Management — scanning, monitoring, assessment, mitigation (§4.3, §4.4)
- Permissions — least-privilege token permissions
Quarterly Review¶
To stay aligned with the ENISA TA and the evolving threat landscape, this library follows a quarterly security review cadence:
- Check the ENISA EU Vulnerability Database (EUVD) and OSV.dev for new advisories affecting actions used in this library.
- Review Dependabot alerts and ensure no open HIGH/CRITICAL findings are older than 30 days without a tracked issue.
- Re-evaluate the compliance matrix above — update status as controls are implemented or gaps are found.
- Review open issues tagged
securityand ensure they have owners and timelines.
The quarterly review should be tracked with an Update Workflow issue using the Security improvement update type.
Attribution¶
Security controls in this section are derived from the ENISA Technical Advisory for Secure Use of Package Managers, v1.1, March 2026. Licensed under CC BY 4.0.