Package Trust Registry
The supply chain problem
When SIGMA certifies a code submission, it reviews the code the developer wrote. But modern Python and Node.js projects are not just the code the developer wrote. They are the code the developer wrote plus everything imported from third-party packages and those packages are never examined by the developer's own review.
A project that imports twenty packages from PyPI or npm is running code written by dozens of people the developer has never met, from repositories they may never have read. Supply chain attacks where a malicious actor publishes a package to a public registry that appears legitimate but contains harmful code are among the most common real-world attack vectors against developer tooling. For AI skills that may run autonomously in agentic workflows, this risk is amplified.
The Package Trust Registry closes this gap.
How it works
When a developer submits a CODE+PACKAGES category submission, SIGMA does not just review the code they wrote. It also reviews every package declared in their dependency manifest.
Step 1 - Dependency extraction. The pre-processor reads the dependency manifest (requirements.txt for Python, package.json for Node.js) and extracts the complete list of declared packages with their declared version specs. If a dependency is expressed as a public-registry range, SIGMA resolves it to one exact version for the submission before audit begins.
Step 2 - Registry lookup. For each package, SIGMA checks its internal Package Trust Registry. If a certificate already exists for that exact package at that exact version, verified by the distribution file's SHA256 hash, the package is considered certified and is included in the submission at no additional cost.
Step 3 - Integrity verification. For packages not already in the registry, SIGMA fetches the package distribution directly from the official registry, PyPI for Python and npm for Node.js. The SHA256 of the downloaded distribution file is computed and compared against the value published by the registry. A mismatch is a critical finding that blocks the submission: it means either the developer's declared version does not match what is actually on the registry, or the registry itself has been tampered with.
Step 4 - Package analysis. Uncertified packages undergo the same static analysis as submitted code: import patterns, shell execution, credential access, network calls, filesystem operations, and secret signals. The analysis runs on the package source: the actual files inside the distribution archive, not metadata about the package. A package certificate is issued following the same council review process as a code submission, using a simplified council prompt tailored for library analysis rather than executable code.
Registry CVE snapshot (advisory data). Before council review, SIGMA queries the same public registries for published security advisories tied to the exact audited version: for npm, the registry's bulk security advisory HTTP API (GitHub Advisory-backed entries when present); for PyPI, the release JSON vulnerabilities list (OSV-backed). Those results are registry-reported facts. They are passed to validators as context, stored on the package certificate, and exposed on public package GET responses so a developer can see "no known CVEs listed" versus "known HIGH-severity advisories" separately from whether the council cleared the package.
Step 5 - Coordination. Package audits for a submission run in parallel. The submission does not proceed to the Senior sandbox until all direct dependencies are resolved. A blocked direct dependency or a blocked first-level transitive dependency (L1) stops the submission before code execution begins. Blocked second- and third-level transitives (L2/L3) are surfaced to the council and certificate as advisory warnings rather than automatic blockers.
Step 6 - Transitive analysis. Beyond direct dependencies, SIGMA expands the dependency graph up to three levels deep (L1-L3). Each discovered transitive package is checked against the Package Trust Registry, and uncached transitives can be fetched and audited just like direct dependencies. Parent attribution is retained, so each transitive can be traced back to the package that pulled it in. To keep submission cost and queue growth bounded, the pipeline enforces a per-submission transitive audit cap; packages beyond that cap are disclosed as uncertified rather than fetched indefinitely.
The flywheel effect
Every package that receives a certificate from any developer's submission joins the shared registry. The next developer who uses that package, regardless of who they are, pays nothing for it. Their submission simply references the existing certificate.
This creates a compounding dynamic: as the registry grows, the cost of certifying a typical project's dependencies decreases. Common packages in the Python and Node.js ecosystems are certified early by the first developers who use them. Over time, the marginal cost of a new submission approaches the base code analysis fee because its dependencies are already certified.
The registry also compounds defensively. A package that is blocked remains visible to future submissions, but the effect depends on where it appears in the dependency tree. A blocked direct dependency or L1 transitive halts the submission immediately. A blocked L2/L3 transitive remains visible to the council and certificate as a warning so the reviewer can reason about depth, package reputation, and the developer's advisory note before reaching a final verdict. Admins can also manually override, block, or revoke and re-audit package certificates when human review is needed.
What gets certified
Only packages available on official public registries are eligible for certification:
- Python packages must be available on PyPI (
pypi.org) - Node.js packages must be available on the npm public registry (
registry.npmjs.org)
Private registries, version control references (git+https://...), and local file paths are not supported. This is intentional: SIGMA cannot issue a certificate for an artifact that is not publicly inspectable. A certificate for a private package would be unverifiable by the developers and agents who rely on it.
Dependencies must resolve to one exact audited version. Exact pins are accepted directly. Public-registry ranges such as >=, ^, and ~= are accepted only when SIGMA can resolve them to one concrete version at submission time and disclose both the declared spec and the exact audited version in the certificate. Wildcards, floating tags, and non-public registry sources are not accepted.
Package certificate security levels
Each package certificate carries a security level that summarises the council's assessment:
| Level | Meaning |
|---|---|
| CLEAR | No security concerns found. Safe to use. |
| MONITORED | Minor concerns noted. Certificate is valid but carries warnings. |
| CAUTION | Significant concerns. Certificate is valid but strong warnings apply. |
| BLOCKED | Rejected. Direct and L1 transitive hits block automatically; L2/L3 hits are surfaced as advisory warnings to the council. |
Warnings from packages are included in the submission certificate so developers and agents can see exactly what the council found.
Verifying a package certificate
Package certificates are publicly queryable. Any developer, agent, or platform can verify whether a specific package version has been certified and what the council found:
GET https://api.soulbyte.tech/api/v1/public/packages/pypi/requests/2.31.0 GET https://api.soulbyte.tech/api/v1/public/packages/npm/axios/1.6.7
The response includes the council verdict, security level, any retained warnings, and a link to the full verification endpoint with integrity details including the distribution SHA256.
Registry coverage statistics are also publicly available:
GET https://api.soulbyte.tech/api/v1/public/packages/stats
This returns the total number of certified packages, coverage of widely used PyPI and npm packages, the total number of submissions that have benefited from cached certificates, and the total cost savings generated by the registry.
Full HTTP details: Package API endpoints.
What the package analysis does not cover
Compiled binary extensions. Some packages include pre-compiled native extensions (.so files on Linux, .pyd on Windows). These are binary artifacts and cannot be statically analysed for source-level security patterns. Their presence is flagged in the certificate. Source-only packages receive a full analysis; packages with binary components receive a partial analysis with that limitation disclosed.
Transitive depth cap. The current version expands and audits transitives up to L3. This is intentionally bounded rather than fully recursive: very large dependency graphs can explode into hundreds of packages. SIGMA enforces a configurable per-submission cap on transitive package audits. Any additional transitives beyond that cap are disclosed as uncertified instead of silently ignored.
Runtime behaviour of libraries. Unlike submitted code, packages are not executed in the Senior sandbox in this version. Libraries do not have entry points in the same sense as executable programs, and running a library in isolation without the context of how it is called produces unreliable results. The analysis is static. Execution analysis for packages with declared CLI entry points is planned for a future version.