| Version | Supported |
|---|---|
| latest | Yes |
| < latest | No |
Only the latest released version receives security updates. Older versions are not maintained.
Do not open a public GitHub issue for security vulnerabilities.
To report a vulnerability, use GitHub Private Vulnerability Reporting.
When reporting, please include:
- Description of the vulnerability
- Steps to reproduce (or proof of concept)
- Affected component (container image, CI workflow, build script, etc.)
- Potential impact assessment
| Stage | Target |
|---|---|
| Acknowledgement | 3 business days |
| Initial assessment | 7 business days |
| Fix or mitigation | 30 calendar days |
We will keep you informed of progress throughout.
The following areas are in scope for security reports:
- Supply chain: GitHub Actions workflows and pinned dependencies
- Container image: Base image vulnerabilities, installed packages, permissions
- Build tooling: Scripts in
scripts/,install.sh,init-workspace.sh - Secrets handling: Accidental exposure of tokens, keys, or credentials
- Workflow permissions: Overly broad permissions in CI/CD pipelines
This repository follows these security practices:
- All GitHub Actions are pinned to commit SHAs (not mutable tags)
- Pre-commit hook repos are pinned to commit SHAs
- Docker base image is pinned to digest in the Containerfile
- Dependabot monitors dependencies for known vulnerabilities
- Dependency review blocks PRs that introduce vulnerable dependencies
- Container images are scanned for vulnerabilities (Trivy) in CI and release
- SBOM (SPDX) is generated and attested for every release
- Released container images are signed with Sigstore cosign (keyless)
- SLSA build provenance attestations are attached to released images
- Workflow permissions follow the principle of least privilege
- Workflow inputs are bound to environment variables (not interpolated inline)
- No
pull_request_targettriggers are used (prevents untrusted code execution) - OpenSSF Scorecard runs weekly to track security posture
- CodeQL static analysis scans Python build tooling
- Branch protection is enforced via GitHub Enterprise
This project is designed to support medical device software development under IEC 62304 and ISO 13485. Security practices align with configuration management and risk management requirements of these standards.
This project accepts and documents known vulnerabilities in test-only dependencies
through expiration-enforced exception registers (.github/dependency-review-allow.txt
and .trivyignore). These exceptions follow an IEC 62304 medtech-compliant risk
assessment model:
Nine vulnerabilities have been accepted in unmaintained legacy BATS test framework dependencies (bats-assert, verbose, reconnect, request, sockjs, engine.io, engine.io-client):
- engine.io (GHSA-r7qp-cfhv-p84w): Uncaught exception leading to DoS
- engine.io (GHSA-j4f2-536g-r55m): Resource exhaustion via large messages
- debug (GHSA-gxpj-cx7g-858c): Regular Expression Denial of Service (ReDoS)
- node-uuid (GHSA-265q-28rp-chq5): Insecure entropy source (Math.random())
- qs (GHSA-6rw7-vpxm-498p): DoS via memory exhaustion (arrayLimit bypass)
- tough-cookie (GHSA-72xf-g2v4-qvf3): Prototype Pollution
- ws (GHSA-6663-c963-2gqg): DoS via large websocket messages
- ws (GHSA-5v72-xg48-5rpm): Denial of Service via malformed frames
- ws (GHSA-2mhh-w6q8-5hxw): Remote memory disclosure
Risk Assessment: All are HIGH or MODERATE severity vulnerabilities from packages last updated 5-10+ years ago. Impact is isolated to CI/development environment with no runtime production code exposure. Expiration dates (2026-11-17) enforce periodic re-evaluation and investigation of BATS framework modernization.
Mitigation: These dependencies are transitive and only used in the test pipeline. Production deployments do not include or execute any test dependencies.