A five-gate validation pipeline that intercepts malicious open source packages — including attacks that pass valid cryptographic signatures — before they reach your application.
id-token: write CI/CD permissions to publish via OIDC — no stored secret required. Packages appeared legitimately signed.Modern supply chain attacks split into two distinct classes that require different defenses.
A compromised maintainer account publishes a malicious release. Automated dependency tooling (Dependabot, Renovate, npm update) ingests it within minutes. The attacker wins the race against the community's ability to detect and revoke the package.
The defense is a time buffer: hold all packages under 72 hours old, hard-block anything under 24 hours. Attackers exploiting automated ingestion get nothing.
An attacker compromises a legitimate employee's GitHub account, pushes orphan commits bypassing PR review, and exploits id-token: write CI/CD permissions to publish via OIDC trusted publishing. The package is correctly signed. Conventional signature verification passes.
The defense is structural: audit the publish pipeline itself — not just the artifact — by checking commit graph reachability, PR provenance, and publisher repo allowlists independently of the compromised repo.
The Miasma / Shai-Hulud attack class produces packages with valid Sigstore signatures — because the attacker controls a real CI/CD pipeline with real OIDC credentials. The signature confirms the package was built by the GitHub Actions runner. It doesn't confirm the code in that build is safe, or that the person who triggered the build had authority to do so. The OSS Trust Framework audits the chain of custody behind the signature, not just the signature itself.
Supply chain integrity layer — not a runtime monitor. This framework validates open source dependencies before they enter your environment. Threats that manifest at runtime (a service beaconing after startup, an MCP server modifying outbound traffic) require complementary runtime tooling such as Falco or Tetragon. These are parallel controls — see the scope boundary.
Each gate queries sources architecturally independent of the package repository. Defeating the framework requires compromising multiple independent systems simultaneously.
When a CVE is filed against a package, an expedited lane bypasses only the age gate. All other gates remain mandatory. Requires machine-verified CVE confirmation + 2-of-3 MFA quorum approval.
Every gate is independently enforced. A pass at Gate 2 does not reduce scrutiny at Gate 5.
Malicious releases depend on automated ingestion speed. A 24-hour hard block breaks that race entirely — a package that can't reach your fleet for a day is a package the community has time to notice, flag, and revoke.
Standard signature verification confirms the artifact was signed by a known key. Provenance attestation verification goes further: it checks where the package was built and whether that location matches your trusted publisher allowlist. This is what catches the Miasma attack class — the signature is valid, but the sourceRepositoryURI points to a fork or employee account rather than the canonical org repo.
npm audit signatures + attestation bundle sourceRepositoryURI checkconfig/trusted_publishers.yaml — maintained in source control, reviewed via PRssourceRepositoryURI in the attestation against your allowlist. A publish from employee-fork/package instead of canonical-org/package is an immediate BLOCK.
This gate class was added specifically in response to the Miasma / Shai-Hulud attacks. It audits the publishing pipeline, not just the published artifact — catching compromised-account attacks that produce legitimately-signed packages.
.github/workflows/*.yml files in the repositoryid-token: write in any publishing workflow without environment protection rulesid-token: write with no environment protection — Gate 2.5b flags this. The release had no associated merged PR — Gate 2.5c blocks this. All three would have stopped the attack independently.
Gate 3 queries sources that are architecturally independent of the package repository. A compromised repo cannot manipulate OpenSSF Scorecard, OSV.dev, or deps.dev. All sources are queried concurrently and a composite score is computed — a single failing source reduces the score rather than blocking alone.
Every dependency update generates an SBOM diff. Unexpected transitive dependency additions are a major injection vector — the XZ Utils attack added a malicious build script through this path. Any new component not in the upstream changelog is flagged for mandatory review.
The 34 behavioral patterns match on what malware does — Tor connections, eBPF syscalls, AI API key access, credential file reads — not what it looks like. Encrypted and obfuscated payloads (IronWorm's unique-per-infection encoding, Miasma v2) are irrelevant to behavioral matching.
You want to protect an existing repo from supply chain attacks. Install the framework and add a GitHub Actions workflow — no cloning, no editable installs.
You want to add behavioral patterns, extend gate coverage, or contribute to the codebase. Clone the repo and install in editable mode.
trusted_publishers.yaml.# Install from PyPI (pending — check back soon) pip install oss-trust-framework # Verify oss-trust --version # oss-trust, version 0.5.1 # Check a package immediately oss-trust check --package requests --version 2.33.0 --ecosystem PyPI --github-repo psf/requests
# Install from PyPI (recommended) pip install oss-trust-framework # Or install latest dev build from GitHub source # pip install "git+https://github.com/chrisgillham/oss-trust-framework.git" # Verify oss-trust --version # oss-trust, version 0.5.1 # Check a package oss-trust check --package requests --version 2.33.0 --ecosystem PyPI --github-repo psf/requests
.github/workflows/ in your own repo. It runs automatically on every PR that touches a lock file — no local install needed for your developers.name: Dependency trust validation on: pull_request: paths: - "**/requirements*.txt" - "**/package-lock.json" - "**/Cargo.lock" - "**/go.sum" - "**/pyproject.toml" jobs: trust-check: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-python@v5 with: python-version: "3.12" - name: Install OSS Trust Framework run: | pip install oss-trust-framework - name: Validate dependency updates env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} run: | # Replace with your package name, version, and ecosystem oss-trust check --package "requests" --version "2.33.0" --ecosystem "PyPI" --github-repo "psf/requests" --output json | tee trust-result.json # Exit code 1 on BLOCKED or QUARANTINE — fails the PR python -c "import json,sys; r=json.load(open('trust-result.json')); sys.exit(0 if r['outcome']=='approved' else 1)"
# Full pipeline check — standard lane oss-trust check --package requests --version 2.33.0 --ecosystem PyPI --github-repo psf/requests # Gate Passed Decision # age yes pass (1732h old) # oob_trust yes PASS (score: 93/100, vulns: 0) # JSON output for scripting oss-trust check --package requests --version 2.33.0 --ecosystem PyPI --output json | jq .outcome # "approved" # Check a package with active CVEs — expect QUARANTINE oss-trust check --package Pillow --version 9.0.0 --ecosystem PyPI # Outcome: QUARANTINE (14 active CVEs found)
# Step 1: Request an expedited exception # CVE is machine-verified against NVD + OSV + GHSA before proceeding oss-trust zeroday request --cve CVE-2024-XXXXX --package requests --version 2.33.1 --requester security@yourorg.com # CVE confirmed by 3 sources. # Quorum request created # Request ID : a3f9b2c1d4e5 # Approvals : 0 / 2 required Expires: 6 hours # Requester excluded from approver pool # Step 2: Each named approver votes (run independently) oss-trust zeroday approve --request-id a3f9b2c1d4e5 --approver-id approver_001 --mfa-token 123456 # Step 3: Check status oss-trust zeroday status --request-id a3f9b2c1d4e5 # Request a3f9b2c1d4e5: APPROVED
# Map your critical packages to canonical GitHub source repos. # Any provenance attestation from a different repo = BLOCK. # Packages not listed still pass signature check but skip repo-match. npm: "express": "expressjs/express" "@redhat-cloud-services/frontend-components": "RedHatInsights/frontend-components" "lodash": "lodash/lodash" PyPI: "requests": "psf/requests" "cryptography": "pyca/cryptography" require_attestation: # Missing = BLOCK, not just quarantine npm: - "@redhat-cloud-services/frontend-components"
# 1. Clone the framework repo git clone https://github.com/chrisgillham/oss-trust-framework cd oss-trust-framework # 2. Create virtual environment python -m venv .venv .venv\Scriptsctivate # 3. Install in editable mode with dev dependencies pip install -e ".[dev]" # 4. Verify oss-trust --version # oss-trust, version 0.5.1 # 5. Copy and configure environment cp .env.example .env # Edit .env — add GITHUB_TOKEN, SIEM_HEC_ENDPOINT, etc.
# 1. Clone the framework repo git clone https://github.com/chrisgillham/oss-trust-framework cd oss-trust-framework # 2. Create and activate virtual environment python -m venv .venv && source .venv/bin/activate # 3. Install in editable mode with dev dependencies pip install -e ".[dev]" # 4. Verify oss-trust --version # oss-trust, version 0.5.1 # 5. Copy and configure environment cp .env.example .env
# Full suite — 131 tests, all offline, under 5 seconds pytest tests/ -v # With coverage (note: oss_trust_framework not src) pytest tests/ -v --cov=oss_trust_framework --cov-report=term-missing # Run a specific gate pytest tests/test_gate5_behavioral.py -v pytest tests/test_zeroday_lane.py -v # Run a single test pytest tests/test_gate5_behavioral.py::test_ironworm_001_tor_onion -v
oss_trust_framework/sbom/differ.py — Gate 4 SBOM delta (syft/cdxgen + CycloneDX diff)oss_trust_framework/sandbox/runner.py — Gate 5 sandbox runner (gVisor + event feed to behavioral_patterns)oss_trust_framework/signature/gpg.py — Gate 2 GPG fallback for non-Sigstore ecosystems# Install from PyPI pip install oss-trust-framework # Copy config templates cp .env.example .env # Fill in GITHUB_TOKEN, SIEM_HEC_ENDPOINT, SLACK_WEBHOOK_URL # Verify installation oss-trust --version
git clone https://github.com/chrisgillham/oss-trust-framework cd oss-trust-framework python -m venv .venv && source .venv/bin/activate pip install -e ".[dev]" cp .env.example .env # Edit .env with your credentials # Run tests pytest tests/ -v --cov=src
# Full pipeline check — standard lane oss-trust check \ --package requests \ --version 2.32.3 \ --ecosystem PyPI \ --github-repo psf/requests # Output (table format) # requests@2.32.3 (PyPI) — lane: standard # Outcome: APPROVED # # Gate Passed Decision # age yes pass (118.3h old) # provenance yes LOW # orphan_commits yes pass # workflow_perms yes pass # pr_provenance yes LOW # oob_trust yes PASS (score: 78/100) # sbom yes pass # sandbox yes pass # JSON output for scripting oss-trust check --package requests --version 2.32.3 \ --ecosystem PyPI --output json | jq .outcome
# Step 1: Request an expedited exception # CVE is machine-verified against NVD + OSV + GHSA before proceeding oss-trust zeroday request \ --cve CVE-2024-XXXXX \ --package requests \ --version 2.32.4 \ --requester security@yourorg.com # Output: # CVE confirmed by 3 sources. # Quorum request created # Request ID : a3f9b2c1d4e5 # Approvals : 0 / 2 required Expires: 6 hours # Step 2: Each named approver runs this independently oss-trust zeroday approve \ --request-id a3f9b2c1d4e5 \ --approver-id approver_001 \ --mfa-token 123456 # TOTP or hardware key # Step 3: Check status oss-trust zeroday status --request-id a3f9b2c1d4e5 # Request a3f9b2c1d4e5: APPROVED
name: Dependency trust validation on: pull_request: paths: - "**/requirements*.txt" - "**/package-lock.json" - "**/Cargo.lock" jobs: validate: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - run: pip install oss-trust-framework - run: | oss-trust check \ --package "${{ env.PACKAGE }}" \ --version "${{ env.VERSION }}" \ --ecosystem "${{ env.ECOSYSTEM }}" \ --github-repo "${{ env.GITHUB_REPO }}" \ --output json > result.json env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
# Map your critical packages to canonical GitHub source repos. # Any provenance attestation from a different repo = BLOCK. # Packages not listed still pass signature check but skip repo-match. npm: "express": "expressjs/express" "@redhat-cloud-services/frontend-components": "RedHatInsights/frontend-components" "lodash": "lodash/lodash" PyPI: "requests": "psf/requests" "cryptography": "pyca/cryptography" require_attestation: # Missing = BLOCK, not just quarantine npm: - "@redhat-cloud-services/frontend-components"
The 72-hour age hold is the highest-ROI control in the framework. But it creates a gap for legitimate zero-day patches that need immediate deployment.
CVE must exist in NVD + OSV + GHSA. 2-of-3 sources required. The patch version must appear in the CVE's "fixed" list — not just be mentioned in the advisory.
Pre-registered named approvers only. Requester cannot approve their own request. TOTP or hardware key required — password alone rejected.
Attestation must postdate CVE publication. A package signed more than 1 hour before the CVE was filed is flagged for manual review.
Orphan commit and PR provenance checks run even in the zero-day lane — a compromised account pushing a "fix" for a CVE it filed is a real attack vector.
Full execution with all 34 behavioral patterns active (18 Miasma + 16 IronWorm). Strace backend on Linux CI; gVisor for strongest isolation.
No 72-hour canary. 100% immediate deploy. Elevated monitoring for 48 hours with auto-rollback on any runtime anomaly or new CVE filing against this version.
The expedited lane automatically suspends to prevent abuse or normalization of the bypass path.
The rule that the requester cannot approve their own exception is hard-coded in the quorum manager, not configurable at runtime. This prevents emergency pressure from being used to lower controls in the moment they matter most.
Three active attack campaigns using two distinct but related playbooks. Here is exactly how each step is intercepted by the framework.
A compromised Red Hat employee GitHub account pushed orphan commits to two RedHatInsights repositories. A CI/CD workflow with id-token: write permission requested a GitHub OIDC token and authenticated directly with npm's trusted publishing endpoint — publishing backdoored versions of 32 packages. Packages carried valid Sigstore signatures. The payload (Miasma v2) collected GCP and Azure cloud identities and generated a unique encrypted payload per infection to defeat hash-based IOCs. Same fundamental pattern also used against TanStack (170 packages) and Bitwarden CLI.
A Rust-built infostealer distributed via 36 malicious npm packages published from the compromised asteroiddao account. A ~976 KB Rust ELF binary is dropped via a preinstall hook (UPX-packed with overwritten magic bytes). The payload hides behind an eBPF kernel rootkit for process and socket hiding, harvests 86 environment variables and 20+ credential file paths — including OpenAI, Anthropic, and AWS credentials, SSH keys, Vault tokens, Kubernetes secrets, and Exodus cryptocurrency wallet seed phrases — then beacons to a Tor hidden service with temp.sh as fallback exfil. Self-propagates by using stolen npm OIDC credentials to publish trojanized versions of victim-owned packages. Backdates commits to obscure forensic timeline. Identified as an evolved variant of the Shai-Hulud worm family.
| Attack step | Gate | Mechanism | Verdict |
|---|---|---|---|
| Orphan commit pushed directly, bypassing PR review | 2.5a | BFS walk from default branch tip. Tag commit not reachable from main → orphan detected | BLOCK |
| No code review on malicious commit — single account merge | 2.5c | Commit→PR API check. No associated merged PR → DIRECT_PUSH → CRITICAL | BLOCK |
Workflow has id-token: write with no environment protection |
2.5b | YAML parsed. id-token: write in publishing workflow without branch protection → CRITICAL finding | QUARANTINE |
| Published from employee fork, not canonical RedHatInsights org repo | 2 | sourceRepositoryURI in npm provenance attestation checked against trusted_publishers.yaml → mismatch | BLOCK |
| Package published less than 24 hours after compromise | 1 | Registry timestamp < 24 h → hard block. No CVE filed → expedited lane unavailable | BLOCK |
| Payload requests OIDC token during install | 5 | MIASMA-010: network event to token.actions.githubusercontent.com → CRITICAL behavioral pattern | BLOCK |
| Payload harvests GCP cloud identity via metadata server | 5 | MIASMA-002: network event to metadata.google.internal → CRITICAL behavioral pattern | BLOCK |
| Payload harvests Azure/AWS identity via IMDS endpoint | 5 | MIASMA-001: network event to 169.254.169.254 → CRITICAL behavioral pattern | BLOCK |
| Unique encrypted payload per infection defeats hash IOCs | 5 | Behavioral pattern matching is event-type based — encryption is irrelevant to what the network destination is | BLOCKED |
| Reads OIDC_PACKAGES env var to enumerate target packages | 5 | ENV-002: env_access event matching OIDC_PACKAGES pattern → CRITICAL | BLOCK |
| IronWorm — asteroiddao / Arweave ecosystem (JFrog, 2026-06-03) | |||
| Rust ELF binary dropped via npm preinstall hook (tools/setup, UPX-packed) | 5 | IRONWORM-002b: process event matching tools/setup execution → CRITICAL | BLOCK |
| eBPF kernel rootkit loaded for process/socket hiding | 5 | IRONWORM-002: bpf() / BPF_PROG_LOAD syscall from install context → CRITICAL | BLOCK |
| Harvests OpenAI, Anthropic, AWS, and other API keys from environment | 5 | IRONWORM-003: env_access matching OPENAI_API_KEY, ANTHROPIC_API_KEY etc. → CRITICAL | BLOCK |
| Beacons to Tor hidden service C2 (.onion) | 5 | IRONWORM-001: network event to .onion destination → CRITICAL (also blocked by --network=none) | BLOCK |
| Fallback exfil via temp.sh | 5 | IRONWORM-001c: network event to temp.sh → CRITICAL (also blocked by --network=none) | BLOCK |
| Steals Exodus cryptocurrency wallet seed phrases | 5 | IRONWORM-005/005b: file_read event on ~/.config/Exodus path → CRITICAL | BLOCK |
| Reads .npmrc and npm tokens for self-propagation via OIDC Trusted Publishing | 5 | IRONWORM-006/006b: .npmrc file read + NPM_AUTH_TOKEN env access → HIGH/CRITICAL | BLOCK |
| Overwrites GitHub Actions workflows to exfiltrate repo secrets | 5 | IRONWORM-007: file write to .github/workflows/ from install context → CRITICAL | BLOCK |
| Backdated commits to obscure forensic timeline | 2.5a | Orphan commit BFS walk checks graph reachability — timestamps are irrelevant to graph position | BLOCK |
| Steals Vault tokens and Kubernetes secrets | 5 | IRONWORM-004/004b: VAULT_TOKEN env var + /root/.vault-token file access → CRITICAL | BLOCK |
Bypassing this framework requires compromising NVD + OSV + GHSA (for the zero-day lane), OpenSSF Scorecard + deps.dev (Gate 3), the npm/PyPI provenance attestation system (Gate 2), and the gVisor sandbox runtime (Gate 5) — simultaneously. No single compromised account, repository, CI/CD pipeline, or rootkit is sufficient. IronWorm's eBPF rootkit cannot escape the gVisor kernel boundary — behavioral patterns fire before the rootkit achieves persistence.
Valid Sigstore signatures do not confirm safe code or authorized publishing. The framework audits the chain of custody behind the signature — commit graph, PR review, publisher repo identity.
The expedited lane gives security teams a safe way to accelerate critical patches without disabling controls. Machine-verified CVE + 2-of-3 MFA quorum — speed and safety aren't in conflict.
Most supply chain controls rely on people following processes. This framework enforces controls architecturally — separation of duties and MFA requirements are code, not policy documents.
Every gate decision, exception, and approval emits a structured SIEM event. Ticket linkage is mandatory. Monthly retrospectives are enforced by circuit breaker. Built to satisfy auditors who weren't in the room.
The included GitHub Actions workflow fires on any lock file change, comments gate results on PRs, and fails the build on block/quarantine. No per-repo configuration after initial setup.
34 named patterns match on what malware does — IMDS requests, OIDC token grabs, credential file reads, Tor connections — not what it looks like. Unique encrypted payloads (Miasma v2) don't defeat behavioral matching. Active on Linux CI via strace.
The framework directly addresses all 10 of the OWASP Top 10 CI/CD Security Risks. The table below maps each risk to the specific gates that implement the control.
| Risk | OWASP description | How the framework addresses it | Gates |
|---|---|---|---|
| CICD-SEC-1 | Insufficient Flow Control Mechanisms | The 24 h hard block and 72 h hold enforce mandatory flow controls on every dependency update. The zero-day lane requires machine-verified CVE confirmation and 2-of-3 MFA quorum before bypassing the age gate — no single individual can accelerate a release. | Gate 1 ZD lane |
| CICD-SEC-2 | Inadequate Identity and Access Management | Gate 2.5b audits dangerous publishing permissions (id-token: write). Gate 2.5c enforces minimum reviewer counts. The zero-day quorum enforces separation of duties — the requester is hard-coded out of the approver pool. |
Gates 2.5b 2.5c, ZD |
| CICD-SEC-3 | Dependency Chain Abuse PRIMARY THREAT | The core mission of the framework. Gates 0–5 validate every dependency update — name similarity, age, signature, CI/CD pipeline integrity, out-of-band trust, SBOM delta, and behavioral sandbox. Gate 5 behavioral sandbox active (strace on Linux CI; gVisor for strongest isolation). | Gates 1–5 |
| CICD-SEC-4 | Poisoned Pipeline Execution (PPE) Miasma class | Gate 2.5a detects orphan commits — direct pushes bypassing the merge queue. Gate 2.5c confirms every release traces to a reviewed merged PR. Gate 2.5b flags exploitable pipeline permissions. Miasma / Shai-Hulud is a confirmed real-world PPE campaign stopped by Gate 2.5. | Gates 2.5a 2.5b, 2.5c |
| CICD-SEC-5 | Insufficient PBAC (Pipeline-Based Access Controls) | Gate 2.5b enforces PBAC by auditing id-token: write, contents: write, and packages: write in publishing workflows, and requiring compensating controls (branch protection, CODEOWNERS, environment protection rules). |
Gate 2.5b |
| CICD-SEC-6 | Insufficient Credential Hygiene IronWorm class | Gate 5 behavioral patterns cover credential harvesting (CRED-001–005, IRONWORM-003/004/006). Gate 2 catches stolen OIDC token misuse via sourceRepositoryURI mismatch. Gate 5 behavioral patterns active — credential harvesting (CRED-001–005, IRONWORM-003/004/006) detected at install time. | Gates 2, 5 |
| CICD-SEC-7 | Insecure System Configuration | Gate 2.5b checks for insecure CI/CD configuration: dangerous permissions without compensating controls, missing branch protection, and absent CODEOWNERS files. The framework actively scans publisher repositories for configuration weaknesses before approving a package. | Gate 2.5b |
| CICD-SEC-8 | Ungoverned Usage of 3rd Party Services | Gate 3 queries OpenSSF Scorecard, OSV, deps.dev, and GitHub Advisories to independently score every third-party dependency. Gate 4 SBOM delta catches unexpected transitive dependencies. trusted_publishers.yaml governs which external publisher repos are trusted per package. |
Gates 3, 4 |
| CICD-SEC-9 | Improper Artifact Integrity Validation | Gate 2 verifies Sigstore / GPG signatures and cross-checks sourceRepositoryURI in provenance attestations against the trusted publishers allowlist. Gate 4 pins exact lock file hashes. Gate 2.5a confirms tagged commits are reachable from the default branch — preventing detached artifact publishing. |
Gates 2 2.5a, 4 |
| CICD-SEC-10 | Insufficient Logging and Visibility | Every gate decision emits a structured SIEM event. Zero-day exceptions require ticket linkage before deployment. Quorum events — including MFA failures and duplicate votes — are emitted immediately. Monthly retrospectives enforced by circuit breaker. Complete, non-repudiable audit trail for every dependency decision. | All gates ZD lane |
Run all six scenarios with the companion demo repo. Each scenario exercises a different gate or attack family.
Standard check, CVE detection, age gate, IronWorm patterns, Miasma patterns, zero-day quorum workflow.
Full test suite covering every gate, all 34 behavioral patterns, and the complete zero-day quorum lifecycle.
Demo uses mocked registry responses and synthetic sandbox events — safe to run anywhere.
The framework validates dependencies before they enter your environment. This is distinct from — and complementary to — runtime security monitoring.
| Threat | Framework coverage | Complementary control |
|---|---|---|
| Malicious install script (IronWorm preinstall hook) | ✓ Active — Gate 5 strace/gVisor sandbox running on Linux CI | — |
| Compromised publisher account (Miasma / PPE) | ✓ Full — Gates 2, 2.5a, 2.5b, 2.5c | — |
| Typosquat / name impersonation (postmark-mcp-evil) | ✓ Full — Gate 0 name similarity (3 algorithms) | — |
| Known CVE in dependency | ✓ Full — Gate 3 OOB trust (OSV, GHSA, Scorecard) | — |
| Runtime exfiltration — MCP server BCC'ing outbound email, library beaconing after startup | ✗ Out of scope — this framework validates at install time only | Falco, Tetragon, eBPF-based runtime monitoring |
| Deferred activation — payload triggered by condition after install | ✗ Out of scope | Runtime monitoring + behavioral analysis in production |
| Semantic impersonation — secure-requests impersonating requests (low string similarity) | ✗ Not detected — Gate 0 requires string similarity; semantic matching not implemented | Manual allowlist review; socket.dev / package reputation scoring |
Gate 5 is fully operational. The sandbox runner executes real package installs via strace on Linux CI and via gVisor for strongest isolation. All 34 behavioral patterns (18 Miasma + 16 IronWorm) are active. Install gVisor for production use — see the setup guide linked below.
Gate 5 setup guide (gVisor + strace) →