Initial readiness review underway. Evidence collection from the controls below is live; formal audit kicks off when our trust partner finalises scope.
Trust & compliance
How PkgRadar evidence maps to your audit.
PkgRadar is a young company building toward formal certifications. Today we give you concrete, auditable evidence that supports your existing controls under SOC 2, NIST SSDF, ISO 27001, the EU Cyber Resilience Act, and SLSA. This page is the file you hand to your auditor.
Customer scan history lives in a single SQLite store on a hardened DigitalOcean droplet. Cloudflare Tunnel handles ingress; no inbound ports are open to the internet.
The scanner does not run npm install, pip install, gem install, cargo build, build-time Java code, dotnet add, composer install, or any other package code. Artifacts are fetched, hashed, and inspected statically under size limits.
Stripe (billing), Resend (transactional email), Cloudflare (edge + tunnel). Listed below with their scope.
Framework
SOC 2 (Trust Services Criteria 2017)
PkgRadar's continuous package release monitoring across npm, PyPI, RubyGems, Cargo, Maven, NuGet, Composer, Go, and Pub, static evidence reports, and CI gate decisions provide auditable evidence for the following Common Criteria.
CC7.1Detection & monitoring of system componentsContinuous static inspection of every fresh release across the nine supported registries produces a per-version evidence record that auditors can sample for monitoring coverage.CC7.2Monitoring of system anomaliesCampaign-hunter flags publisher bursts, payload-host reuse, and TTP correlation across releases — concrete records for anomaly review.CC7.3Evaluation of security eventsPer-package status history shows transitions (clean → review → high risk) with timestamps, supporting incident review evidence.CC8.1Change management for ICT componentsThe /gate/<ecosystem> endpoints block dependency changes that match high-risk static evidence at PR time — a documented control over change ingress.CC9.2Vendor & third-party riskEvery third-party package is a vendor. PkgRadar provides per-publisher posture and release-by-release evidence for the vendor risk file.Framework
NIST SSDF v1.1 (SP 800-218)
PkgRadar implements practices and tasks from the Produce Well-Secured Software (PW) and the supporting PO/PS categories.
PW.4Reuse existing, well-secured software when feasiblePre-build static analysis (no execution) of acquired open-source components, with provenance and risk signal per version.PW.4.1Acquire and maintain a list of approved third-party componentsSaved scan reports + status ledger provide an authoritative inventory of evaluated dependencies and their verdicts.PW.4.4Verify acquired components prior to useTarball hashing, manifest parsing, version-diff findings, and remote-payload following deliver pre-install verification evidence.PW.7.1Perform analysis on software & dependenciesStatic evidence findings (install hooks, credential paths, obfuscation, remote payload fetch) map directly to dependency analysis.RV.1Identify & confirm vulnerabilities on an ongoing basisCampaign-hunter continuously rescans every supported registry — vulnerabilities and active compromises detected post-release flow into the same evidence stream.Framework
ISO/IEC 27001:2022 (Annex A)
Several Annex A controls require evidence of supply-chain inspection and secure coding hygiene that PkgRadar can directly source.
A.5.21Managing information security in the ICT supply chainPer-package evidence, publisher posture, and gate decisions form the supplier evaluation file for open-source dependencies.A.5.22Monitoring, review and change management of supplier servicesRe-scans on every fresh release detect supplier behaviour changes (new lifecycle scripts, new remote dependencies).A.8.28Secure codingCI gate enforces dependency hygiene at the source — secure coding implementations can cite the gate config as the technical control.A.8.30Outsourced developmentTreats third-party packages as outsourced code: static review, evidence retention, and refusal of high-risk artefacts.Framework
EU Cyber Resilience Act (CRA)
Manufacturers placing products with digital elements on the EU market must demonstrate due diligence on their components and ongoing vulnerability handling.
Annex I §1Cybersecurity essential requirementsStatic scanning of dependencies before integration evidences component due diligence required by the essential requirements.Annex I §2Vulnerability handling requirementsContinuous monitoring of dependencies plus alerts on flips to high-risk give documented vulnerability handling coverage.Article 13Obligations of manufacturers (due diligence)Saved evidence reports + gate decisions form the technical-documentation file for components in scope.Framework
SLSA (Supply-chain Levels for Software Artifacts) v1.0
PkgRadar supports the Dependency-Source verification track and complements build-provenance work upstream.
Dependencies — Track 1+Source review & dependency evaluationStatic evidence per release contributes to dependency-track requirements that consumers verify before promotion.Producer — L2Two-person review of imported artefactsAdmin review/promote/dismiss workflow on campaign candidates supports an audit trail for artefact intake decisions.Sub-processors
Who handles your data
| Vendor | Purpose | Data shared | Region |
|---|---|---|---|
| Stripe | Subscription billing & webhook signing | Email, payment method (Stripe-tokenised) | US / EU |
| Resend | Transactional email (sign-in, alerts) | Email address, message body | US |
| Cloudflare | Edge TLS termination + tunnel ingress | Request metadata; no body retention | Global edge |
| DigitalOcean | Compute hosting | Application + scan database | NYC |
Procurement
Need a DPA, security questionnaire, or detailed control narrative?
Send the questionnaire or specific control language and we’ll return mapped responses alongside the evidence on this page. We aim to be responsive on security reviews but don’t commit to a specific turnaround until an enterprise agreement is in place.