penthera 1.7.0 → 1.8.0

package/docs/compare/github.md

@@ -1,60 +0,0 @@
-# Penthera and GitHub (Dependabot and code scanning)
-
-*Last checked: 2026-10-19 against GitHub's docs and security plans page.*
-
-## Use them together
-
-If your code is on GitHub, you probably have Dependabot already. It alerts you
-when a dependency has a known, reviewed vulnerability and opens a pull request
-to the patched version. Code scanning with CodeQL finds bugs in your own code.
-Penthera covers what those do not look at: what a package can do when it has no
-advisory yet, the running app, and your AI tooling. Its SARIF output uploads
-into the same code scanning tab, so findings sit in one place.
-
-## Side by side
-
-| | Penthera | Dependabot and code scanning |
-|---|---|---|
-| Dependencies | Capabilities and the upgrade diff, typosquats, licenses; npm and Python | Alerts from GitHub-reviewed advisories in the GitHub Advisory Database ([alerts](https://docs.github.com/en/code-security/dependabot/dependabot-alerts/about-dependabot-alerts)); security and version update PRs |
-| Pull requests | Action that comments the capability diff | Dependency review action that can block a vulnerable change ([dependency review](https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/about-dependency-review)) |
-| Your code | Routes, trust boundaries, secrets (JS/TS frameworks) | CodeQL queries across many languages |
-| Secrets | Repo scan and a pre-commit hook on staged files | Secret scanning and push protection ([features](https://docs.github.com/en/code-security/getting-started/github-security-features)) |
-| Running app | URL scan | No |
-| AI tooling | `penthera agents` | No dedicated check |
-| Where it runs | Your machine or any CI, offline | GitHub; the CodeQL CLI also runs locally ([CodeQL CLI](https://docs.github.com/en/code-security/codeql-cli/getting-started-with-the-codeql-cli/about-the-codeql-cli)) |
-| Cost | Free | Dependabot is free on all plans. Code scanning, dependency review and secret scanning are free on public repos; private repos need GitHub Code Security ($30) or Secret Protection ($19) per active committer a month ([plans](https://github.com/security/plans)) |
-
-## Where GitHub goes further
-
-- **Known-vulnerability coverage** across ecosystems, with update pull requests
-  generated for you. Penthera does not open pull requests at all.
-- **CodeQL** is a far deeper code analyser than Penthera's repo scan.
-- **Push protection** stops secrets on the server side, for every contributor,
-  without anyone installing a hook.
-- **Zero setup** for public repositories.
-
-## Where Penthera adds something
-
-- **Before an advisory exists.** Dependabot needs a reviewed advisory. Penthera's
-  capability diff shows a new install script or network call on the day it
-  appears.
-- **The live app and your agent setup**, which GitHub's tools do not scan.
-- **Private repos without a GitHub Advanced Security licence**, and code that is
-  not on GitHub.
-
-## Run both
-
-Keep Dependabot and code scanning on. Add Penthera's action for the capability
-diff ([docs/commands/action.md](../commands/action.md)) and upload its SARIF:
-
-```yaml
-- run: npx penthera@1.7.0 "$PREVIEW_URL" --sarif reports/scan.sarif
-- uses: github/codeql-action/upload-sarif@6f2ac81f5cd81fe351a197ba0b00d91d03cd2aee # v4.39.0
-  with:
-    sarif_file: reports/scan.sarif
-```
-
-Uploading SARIF to code scanning in a private repository also needs GitHub Code
-Security.
-
-[All comparisons](README.md) · [Back to the README](../../README.md)

package/docs/compare/semgrep.md

@@ -1,54 +0,0 @@
-# Penthera and Semgrep
-
-*Last checked: 2026-10-19 against Semgrep's docs, GitHub and pricing page.*
-
-## Use them together
-
-[Semgrep](https://semgrep.dev) is a static analyser for your own code. The
-Community Edition engine is open source (LGPL-2.1) and runs locally; the
-commercial AppSec Platform adds cross-file analysis, supply-chain reachability,
-secrets and AI triage ([CE vs platform](https://docs.semgrep.dev/semgrep-pro-vs-oss)).
-Penthera's repo scan is narrower than Semgrep's. What Penthera adds is the rest
-of the picture: the running app, what your dependencies can do, and your AI
-tooling.
-
-A reasonable setup: Semgrep on every pull request for code patterns, with your
-own rules if you write them. Penthera for the lockfile, the preview URL and the
-agent config.
-
-## Side by side
-
-| | Penthera | Semgrep |
-|---|---|---|
-| Your code | Route discovery, trust-boundary mapping and secrets for Next.js, Express, Hono, Fastify | Pattern-based analysis in many languages; CE works within a single file, the platform adds cross-file taint analysis ([CE vs platform](https://docs.semgrep.dev/semgrep-pro-vs-oss)) |
-| Rules | Built in and readable; no rule language for users | A rule language plus 2,000+ community rules in the Registry ([repo](https://github.com/semgrep/semgrep)) |
-| Dependencies | Capabilities, upgrade diff, typosquats, licenses (npm and Python) | Semgrep Supply Chain with reachability, on the platform |
-| Running app | URL scan | No |
-| AI tooling | `penthera agents` | No dedicated check |
-| Network | None needed | CE with local rules sends no metrics by default; `--metrics=off` turns them off ([metrics](https://docs.semgrep.dev/metrics)) |
-| Cost | Free, MIT | CE is free. Platform free for up to 10 contributors; Teams from $30 per contributor a month per product ([pricing](https://semgrep.dev/pricing)) |
-
-## Where Semgrep goes further
-
-- **Code analysis depth and breadth**: many languages, and dataflow across files
-  on the platform.
-- **Your own rules.** If your team has patterns to ban, Semgrep's rule language
-  is the right tool. Penthera has no user rule language for code.
-- **Reachability** for dependency vulnerabilities.
-
-## Where Penthera adds something
-
-- **Outside the source**: the running app, what packages do when installed, and
-  the agent config on your machine.
-- **Fixes that are verified** by a re-scan on a local branch.
-- **EU evidence** from the same runs.
-
-## Run both
-
-```bash
-semgrep scan --config p/default --sarif -o semgrep.sarif
-npx penthera http://localhost:3000 --repo . --sarif penthera.sarif
-npx penthera deps --base origin/main
-```
-
-[All comparisons](README.md) · [Back to the README](../../README.md)

package/docs/compare/snyk.md

@@ -1,62 +0,0 @@
-# Penthera and Snyk
-
-*Last checked: 2026-10-19 against Snyk's public docs, pricing page and GitHub.*
-
-## Use them together
-
-[Snyk](https://snyk.io) is a developer security platform built around a curated
-vulnerability database: it tells you which of your dependencies, containers and
-infrastructure files have known issues, across many languages, and opens fix
-pull requests. Penthera asks different questions: what can a package do (not
-only which CVEs it has), how does the running app behave, and what is in your
-AI tooling config. It does this offline and without an account.
-
-A reasonable setup: Snyk for known-vulnerability coverage across your stack.
-Penthera for the behaviour diff on lockfile changes, the scan of your preview
-URL before a deploy, and the agent-config audit.
-
-## Side by side
-
-| | Penthera | Snyk |
-|---|---|---|
-| Dependencies | What each npm and Python package can do (install scripts, shell, network, env, obfuscation), what an upgrade added, typosquats, licenses | Known vulnerabilities and licenses across 13+ package ecosystems ([supported languages](https://docs.snyk.io/supported-languages/supported-languages-package-managers-and-frameworks)) |
-| Your code | Route discovery, trust boundaries and secrets for JS/TS frameworks | Snyk Code static analysis in 16 languages ([supported languages](https://docs.snyk.io/supported-languages/supported-languages-package-managers-and-frameworks)) |
-| Running app | URL scan (headers, TLS, CORS, auth, JWT, IDOR, OAuth, OpenAPI; opt-in injection and fuzzing) | Snyk API & Web, a DAST product on Enterprise plans ([plans](https://snyk.io/plans/)) |
-| Containers, IaC | No | Yes ([CLI](https://docs.snyk.io/developer-tools/snyk-cli)) |
-| AI tooling | `penthera agents`: skills, MCP servers, hooks, permissions, plugins, rule files, checked locally | Snyk Agent Scan: MCP servers and skills, sends component metadata to Snyk's API and needs a token ([agent-scan](https://github.com/snyk/agent-scan)) |
-| Account | None | Required for the CLI ([authenticate](https://docs.snyk.io/developer-tools/snyk-cli/authenticate-to-use-the-cli)) |
-| Fixes | Deterministic recipes as local diffs, re-scanned to verify; never pushes | Fix pull requests through SCM integrations ([fix PRs](https://docs.snyk.io/scan-with-snyk/pull-requests/snyk-fix-pull-or-merge-requests)) |
-| Editor | Through your coding agent (Agent Skill) | Plugins for VS Code, JetBrains, Visual Studio, Eclipse ([IDE](https://docs.snyk.io/developer-tools/snyk-ide-plugins-and-extensions)) |
-| Licence | MIT | CLI is Apache-2.0 ([repo](https://github.com/snyk/cli)); the platform is commercial |
-| Cost | Free | Free plan with 5 projects and 100 Snyk Code tests a month; Team from $25 a month ([plans](https://snyk.io/plans/)) |
-
-## Where Snyk goes further
-
-- **Curated vulnerability data** across many languages, with advisories written
-  and maintained by a research team. Penthera does not track CVEs for your
-  dependencies beyond the vendored Retire.js database for front-end scripts.
-- **Breadth**: containers, infrastructure as code, many more languages.
-- **Reachability analysis** to cut a CVE list down to what you call.
-- **Organisation features**: dashboards, policies across many repos, reporting.
-
-## Where Penthera adds something
-
-- **Behaviour, not only known issues.** A new install script or a package that
-  suddenly reads your whole environment shows up even when no CVE exists yet.
-- **The running app**, free, on localhost.
-- **Fully local.** No account, no API calls, nothing about your code leaves the
-  machine. The AI-tooling audit is local too.
-- **EU evidence**: NIS2 readiness, CRA report drafts, SBOM and AI-BOM, and a
-  signable evidence bundle.
-
-## Run both
-
-```bash
-snyk test                               # known vulnerabilities in dependencies
-npx penthera deps --base origin/main    # what the new packages can do
-npx penthera http://localhost:3000 --repo .
-```
-
-Both write SARIF, so both can upload to GitHub code scanning.
-
-[All comparisons](README.md) · [Back to the README](../../README.md)

package/docs/compare/socket.md

@@ -1,78 +0,0 @@
-# Penthera and Socket
-
-*Last checked: 2026-10-19 against Socket's public docs and pricing page.*
-
-## Use them together
-
-[Socket](https://socket.dev) watches the open-source registries for malicious and
-risky packages and tells you about them in pull requests, in your editor and at
-install time. Penthera runs on your machine and checks the app you built, the
-packages already in your lockfile, and the AI tooling you build it with.
-
-A reasonable setup: Socket's GitHub app or firewall on every dependency change,
-because it watches new releases across the registries and Penthera does
-not. Penthera before each deploy, for the app scan, the agent-config audit
-and the evidence, and anywhere a network call or an account is not an option.
-
-## Side by side
-
-| | Penthera | Socket |
-|---|---|---|
-| Main question | Is the thing I am about to ship safe, and can I prove it? | Is this package safe to depend on? |
-| Scope | Your running app (URL scan), your source (repo scan), your dependencies, your AI tooling (skills, MCP, hooks), fixes, NIS2 and CRA evidence | Packages across many ecosystems, plus browser extensions and AI models ([language support](https://docs.socket.dev/docs/language-support)) |
-| Ecosystems for dependencies | npm and Python | JS/TS, Python, Go, Java, Ruby, .NET, Rust and more ([language support](https://docs.socket.dev/docs/language-support)) |
-| How it decides | Deterministic rules in the repo, with `file:line` evidence and a confidence label | Static analysis followed by an LLM stage, with researchers confirming detections ([AI alert](https://socket.dev/alerts/gptMalware)) |
-| Threat intelligence | None beyond what ships in a release | Registry-wide and continuously updated |
-| Network | None needed; `--offline` limits traffic to the target you named | The CLI and firewall query Socket's API ([CLI](https://github.com/SocketDev/socket-cli), [firewall](https://docs.socket.dev/docs/socket-firewall-overview)) |
-| Account | None | API token for the CLI; the firewall's free wrapper mode needs no key ([firewall](https://docs.socket.dev/docs/socket-firewall-overview)) |
-| Install-time guard | `penthera install`: reviews capabilities and install scripts before any script runs (npm) | Socket Firewall (`sfw`): blocks known-malicious packages for npm, yarn, pnpm, pip, uv and cargo in free mode |
-| Pull requests | GitHub Action that comments the capability diff | GitHub app that comments on risky dependency changes ([docs](https://docs.socket.dev/docs/socket-for-github)) |
-| AI tooling | Audits the skills, MCP servers, hooks, permissions and plugins already on disk | An MCP server agents can use to look up package scores ([MCP guide](https://docs.socket.dev/docs/guide-to-socket-mcp)); firewall coverage for agent skills and AI models as downloads ([firewall](https://socket.dev/features/firewall)) |
-| App security | URL and repo scans, fix recipes | Not its focus; SAST and secrets are on the Enterprise plan ([pricing](https://socket.dev/pricing)) |
-| SBOM | CycloneDX SBOM and AI-BOM, free | Business plan and up ([pricing](https://socket.dev/pricing)) |
-| Licence | MIT | `socket` CLI and MCP server MIT; `sfw` under PolyForm Shield 1.0.0 (source-available) ([sfw-free](https://github.com/SocketDev/sfw-free)) |
-| Cost | Free | Free plan (1 seat, 1,000 scans a month); free Business plan for OSI-licensed public projects ([announcement](https://socket.dev/blog/free-business-plan-upgrades-for-open-source)); paid seats from $25 a month ([pricing](https://socket.dev/pricing)) |
-
-## Where Socket goes further
-
-- **It sees the whole registry.** A freshly published package with a
-  credential stealer in it can be flagged by Socket before you install it.
-  Penthera only sees what is in front of it, with rules from its last release.
-- **More ecosystems.** Penthera's dependency checks cover npm and Python today,
-  and its install firewall covers npm only.
-- **Human research.** Socket's researchers confirm and publish malware
-  findings. Penthera has no threat-research team.
-- **Reachability** on paid plans, which narrows a long CVE list to the code paths
-  you call.
-
-## Where Penthera adds something
-
-- **Your app, not only its packages.** Headers, auth, IDOR, OAuth, OpenAPI,
-  secrets in source, and fixes that are re-scanned to prove they worked.
-- **The AI tooling on your machine.** `penthera agents --home` reads your Claude
-  Code, Cursor and MCP config and flags hidden instructions, unpinned servers and
-  over-broad permissions.
-- **Offline and account-free**, which matters on air-gapped machines, in some
-  public-sector work, and for anyone who cannot send a dependency list to a
-  vendor.
-- **Readable verdicts.** Every finding points at a rule in this repository.
-
-## A note on AI verdicts
-
-Socket's AI scanner once flagged Penthera itself as malware. That is an
-understandable call: Penthera's test suite contains real attack payloads,
-because a security scanner has to be tested against them. It is also a fair
-illustration of the trade-off. An AI stage catches novel malware that no rule
-anticipated, and it can misread intent. Deterministic rules miss what they were
-not written for, and they always tell you exactly why they fired. The two
-approaches cover each other's gaps, which is a good reason to run both.
-
-## Run both
-
-```bash
-sfw npm install            # Socket Firewall: block known-bad packages at install
-npx penthera deps --base origin/main   # what the new packages can do, offline
-npx penthera agents --home             # your AI tooling
-```
-
-[All comparisons](README.md) · [Back to the README](../../README.md)

package/docs/compare/zap.md

@@ -1,59 +0,0 @@
-# Penthera and OWASP ZAP
-
-*Last checked: 2026-10-19 against zaproxy.org and the ZAP GitHub repositories.*
-
-## Use them together
-
-[ZAP](https://www.zaproxy.org) is the long-standing open-source dynamic scanner
-for web apps: a proxy, spiders, passive and active scan rules, scripting, and an
-automation framework. Since September 2024 it is branded ZAP by Checkmarx and
-remains Apache 2.0 ([announcement](https://www.zaproxy.org/blog/2024-09-24-zap-has-joined-forces-with-checkmarx/)).
-Penthera's URL scan covers a smaller, opinionated set of checks, and pairs them
-with the source code, your dependencies and your AI tooling.
-
-A reasonable setup: Penthera as the quick first pass on every preview URL,
-with source context and fixes. ZAP for deeper dynamic testing, manual
-exploration through its proxy, and anything that needs a logged-in browser crawl.
-
-## Side by side
-
-| | Penthera | ZAP |
-|---|---|---|
-| Dynamic testing | Headers, TLS, CORS, cookies, auth hardening, JWT, IDOR, OAuth, OpenAPI probes; injection and fuzzing are opt-in | Passive and active scan rules, spider and AJAX spider ([features](https://www.zaproxy.org/docs/desktop/start/features/), [AJAX spider](https://www.zaproxy.org/docs/desktop/addons/ajax-spider/)) |
-| API definitions | OpenAPI and FastAPI | OpenAPI, SOAP and GraphQL ([API scan](https://www.zaproxy.org/docs/docker/api-scan/)) |
-| Manual testing | No | Intercepting proxy and desktop UI |
-| Source code | Repo scan in the same run (`--repo .`) maps routes and finds secrets | No |
-| Dependencies, AI tooling | Yes | No |
-| Fixes | Framework-aware fix recipes, re-scanned to verify | Reports alerts |
-| Automation | CLI, GitHub Action, SARIF | YAML Automation Framework, Docker packaged scans, the ZAP Baseline Scan action ([automate](https://www.zaproxy.org/docs/automate/)) |
-| Runtime | Node.js 22+ | Java 17+, or Docker ([download](https://www.zaproxy.org/download/)) |
-| Licence | MIT | Apache 2.0 |
-
-## Where ZAP goes further
-
-- **Depth of dynamic testing**: many more active scan rules, a mature crawler
-  for JavaScript-heavy apps, and years of tuning.
-- **Manual work**: the intercepting proxy lets a person explore and replay.
-- **Authentication**: browser-based, scripted and OAuth2 logins in the
-  automation framework ([automation framework](https://www.zaproxy.org/docs/automate/automation-framework/)).
-  Penthera takes a cookie or bearer token.
-- **Community**: a large add-on ecosystem and documentation.
-
-## Where Penthera adds something
-
-- **Black box and white box together.** A URL finding can point at the route
-  handler in your repo, and the repo scan finds routes the crawler never saw.
-- **Fixes**, applied as diffs on a local branch and re-scanned.
-- **Beyond the app**: dependency capabilities, AI-tooling audit, NIS2 and CRA
-  evidence.
-- **A confidence label on every finding**, so a heuristic match never reads as a
-  confirmed vulnerability.
-
-## Run both
-
-```bash
-npx penthera http://localhost:3000 --repo . --sarif penthera.sarif
-docker run -t ghcr.io/zaproxy/zaproxy:stable zap-baseline.py -t http://host.docker.internal:3000
-```
-
-[All comparisons](README.md) · [Back to the README](../../README.md)

package/docs/compliance-cra.md

@@ -1,141 +0,0 @@
-# Compliance: the Cyber Resilience Act (CRA)
-
-Back to the [README](../README.md). NIS2 lives in
-[compliance-nis2.md](compliance-nis2.md).
-
-The Cyber Resilience Act, [Regulation (EU) 2024/2847](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng),
-puts security duties on manufacturers of products with digital elements, which
-includes software you sell or make available in the EU. Most of it applies from
-11 December 2027. The reporting duty in **Article 14 has applied since
-11 September 2026** (Art. 71(2)), and it also covers products placed on the
-market before December 2027 (Art. 69(3)).
-
-Penthera helps with two pieces of CRA evidence, offline:
-
-| Command | What you get |
-|---------|--------------|
-| `--cra-init cra.json` then `--cra cra.json` | Article 14 timeline with real due dates, overdue flags, and drafts of every report |
-| `--repo . --aibom aibom.cdx.json` | CycloneDX 1.6 AI-BOM: AI SDKs, models referenced in code, MCP servers, skills, prompt files |
-
-Penthera does not make you CRA compliant and does not certify anything. The
-drafts are not the ENISA platform's official form, and none of this is legal
-advice.
-
-## Article 14 reporting helper
-
-### What the regulation asks
-
-Checked on 2026-10-19 against the Official Journal text and the
-[ENISA Single Reporting Platform (SRP) FAQ](https://www.enisa.europa.eu/topics/product-security/vulnerability-services/eu-incident-response-and-cyber-crisis-management/single-reporting-platform-srp/frequently-asked-questions).
-
-| | Actively exploited vulnerability (Art. 14(1)-(2)) | Severe incident (Art. 14(3)-(5)) |
-|---|---|---|
-| Early warning | within 24 hours of becoming aware, with the Member States where the product is available | within 24 hours, including whether it is suspected to be caused by unlawful or malicious acts, plus Member States |
-| Notification | within 72 hours: the product, the general nature of the exploit and the vulnerability, corrective or mitigating measures taken and ones users can take, how sensitive the information is | within 72 hours: nature of the incident, an initial assessment, measures taken and ones users can take, sensitivity |
-| Final report | no later than **14 days after a corrective or mitigating measure is available**: description with severity and impact, any malicious actor, details of the security update | within **one month after the incident notification**: detailed description with severity and impact, type of threat or root cause, applied and ongoing mitigations |
-
-- **Where to send it.** Through the [ENISA Single Reporting Platform](https://portal.cra-srp.enisa.europa.eu/),
-  using the end-point of the CSIRT designated as coordinator in the Member State
-  of your main establishment. ENISA receives it at the same time (Art. 14(1),
-  14(3), 14(7)). For the Netherlands that CSIRT is **NCSC-NL**, per ENISA's
-  [list of CSIRTs designated as coordinators](https://www.enisa.europa.eu/topics/product-security/vulnerability-services/eu-incident-response-and-cyber-crisis-management/single-reporting-platform-srp/list-of-csirts-designated-as-coordinators).
-- **Inform your users.** After becoming aware, inform impacted users (and where
-  appropriate all users), with mitigations they can deploy, where appropriate
-  in a machine-readable format (Art. 14(8)).
-- **One notification** per vulnerability or incident, even across subsidiaries
-  (ENISA SRP FAQ). The CSIRT may ask for an intermediate report (Art. 14(6)).
-- An *actively exploited vulnerability* is one with reliable evidence that a
-  malicious actor exploited it without the system owner's permission (Art. 3(42)).
-  An incident is *severe* if it can harm the availability, authenticity,
-  integrity or confidentiality of sensitive or important data or functions, or
-  can lead to malicious code in the product or a user's systems (Art. 14(5)).
-
-### Use it
-
-```bash
-penthera --cra-init cra.json   # set type ("vulnerability" or "incident") and aware_at
-penthera --cra cra.json        # writes cra-reports.md and prints the deadlines
-```
-
-`cra-reports.md` holds the timeline (UTC and your local time), a status per
-report (`due in 21h 30m`, `submitted`, `submitted late`, `OVERDUE`,
-`waiting for a fix`), a draft of each report with `NEEDS INPUT` for every fact
-still missing, and a draft user advisory for Art. 14(8). Record what you've sent
-in `submitted.early_warning` / `submitted.notification` / `submitted.final_report`
-and re-run; for a severe incident the final report then counts from the real
-submission time instead of the 72-hour deadline.
-
-**Prefill from your scan and SBOM.** Name the affected dependency in
-`component.name` and point `prefill` at Penthera output (paths relative to
-`cra.json`):
-
-```json
-{
-  "type": "vulnerability",
-  "aware_at": "2026-10-24T09:00:00+02:00",
-  "component": { "name": "jquery" },
-  "prefill": { "scan": "scan.json", "sbom": "sbom.cdx.json" }
-}
-```
-
-```bash
-penthera https://staging.example.com --repo . --sbom sbom.cdx.json -o scan.json
-```
-
-From the SBOM it fills the product name and version and the component's version
-and purl; from the scan, matching CVE ids, the scanner severity, and the finding
-titles. Prefilled values are marked *verify* in the draft, and anything you wrote
-yourself is never overwritten. A full example lives in `tests/fixtures/cra/`.
-
-### How the deadlines are counted
-
-- **Hours are elapsed hours** from `aware_at`. If the clocks change in between,
-  the local due time shifts (24 hours from 09:00 CEST on 24 October 2026 is
-  08:00 CET on 25 October).
-- **Days and months are calendar periods** in your `timezone` (default
-  `Europe/Amsterdam`), ending at the same clock time. One month from 31 January
-  ends on 28 (or 29) February, following
-  [Regulation 1182/71](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:31971R1182) Art. 3(2)(c).
-- A timestamp without an offset is read in `timezone`. Use ISO 8601.
-- This is the **strict reading**. Regulation 1182/71 can give a little more
-  time (a period runs to the end of the hour or day, and a days or months period
-  that ends on a weekend or public holiday moves to the next working day).
-  Don't plan on that; report early.
-
-The helper warns if `aware_at` is before 11 September 2026, if
-`main_establishment` is not the Netherlands (so NCSC-NL is not your CSIRT), and
-if the type or time zone is unknown.
-
-## AI-BOM (CycloneDX 1.6)
-
-Customers and auditors increasingly ask what AI a product contains: which
-providers get your data, which models, which agent tooling. `--aibom`
-inventories it from the repo, offline:
-
-```bash
-penthera --repo . --aibom aibom.cdx.json
-```
-
-| Found | How | CycloneDX |
-|-------|-----|-----------|
-| AI SDKs: `openai`, `@anthropic-ai/sdk`, `@google/genai`, `ai` / `@ai-sdk/*`, `langchain` / `@langchain/*`, `llamaindex`, `ollama`, `@huggingface/transformers`; on PyPI `anthropic`, `transformers`, `torch`, `langchain-*`, `llama-index-*`, `litellm`, `mcp` and others | lockfile, `package.json`, `requirements.txt`, `pyproject.toml` | `library` with purl |
-| Models: `claude-*`, `gpt-*`, `o3`, `text-embedding-*`, `gemini-*`, `gemma*`, `llama*`, `mistral-*`, `deepseek-*`, `qwen*`, `phi-*`, `grok-*`, Hugging Face ids (`meta-llama/Llama-3.1-8B-Instruct`) | whole string literals in code and `model:` keys in YAML/TOML; HF ids only for known orgs or next to a loader call | `machine-learning-model` with supplier, `modelCard` stub, `evidence.occurrences` (file and line) |
-| MCP servers | `lib/agents/discover.js` (`.mcp.json`, `.cursor/`, `.vscode/mcp.json`, ...) | `services` with transport, package, endpoint and trust boundary; env var *names* only, never values or args |
-| Agent Skills | `SKILL.md` folders | `data` with SHA-256 |
-| Prompt files | `*.prompt`, `*.prompty`, `*.prompt.md`, anything under a `prompts/` folder | `data` with SHA-256 |
-
-Every item hangs off the root component in `dependencies`. The BOM is only the
-AI slice; use `--sbom` for all dependencies.
-
-Spec references: the [CycloneDX 1.6 JSON reference](https://cyclonedx.org/docs/1.6/json/),
-the [ML-BOM capability page](https://cyclonedx.org/capabilities/mlbom/), and the
-[official schema](https://github.com/CycloneDX/specification/blob/master/schema/bom-1.6.schema.json).
-That schema (with its SPDX and JSF dependencies) is vendored in
-`tests/fixtures/cyclonedx/`, and the tests validate every generated AI-BOM
-against it without network. Penthera emits 1.6 (ML-BOM first appeared in 1.5);
-CycloneDX 1.7 is also published and is a later upgrade.
-
-**Limits.** A model string in code means the model is referenced, not that it
-runs in production; the evidence lines let a reviewer check. Model ids built at
-runtime (`` `claude-${tier}` ``) are not detected. The `modelCard` is a stub:
-fill in task, datasets and considerations from the provider's model card.

package/docs/compliance-nis2.md

@@ -1,168 +0,0 @@
-# Compliance: NIS2 and the cyberwetgeving
-
-Back to the [README](../README.md). Shipping a product? The Cyber Resilience
-Act's Article 14 reporting helper and the AI-BOM are in
-[compliance-cra.md](compliance-cra.md).
-
-The EU NIS2 directive and its national transpositions (the Cyberbeveiligingswet
-in the Netherlands, the NIS2-wet in Belgium) put a duty of care, the *zorgplicht*,
-on in-scope organisations. That duty is the set of risk-management measures in
-Article 21(2) of the directive. Most of them are organisational. Some are
-technical and testable, and that is the part Penthera helps with.
-
-Penthera does not make you compliant and does not certify anything. What it gives
-you is automated, repeatable technical evidence for the measures a scanner can
-honestly verify: the kind of artefact you can attach to a risk file, show an
-auditor, or run in CI so a regression shows up before it ships.
-
-| Art. 21(2) measure | What Penthera does | Coverage |
-|--------------------|--------------------|----------|
-| **(a)** Risk analysis & information-security policy | Findings, severity, and baseline history feed your risk analysis | Evidence |
-| **(b)** Incident handling | `--incident` drafts the 24h / 72h / 1-month reports against your authority's required content | Partial |
-| **(c)** Business continuity, backup, crisis management | Organisational; outside a scanner's reach | Out of scope |
-| **(d)** Supply-chain security | Known-CVE checks on JS dependencies, leaked credentials, a CycloneDX SBOM (`--sbom`), and passive supplier rating (`--suppliers`) | Partial |
-| **(e)** Security in acquisition, development & maintenance; **vulnerability handling** | The core: black- + white-box scanning mapped to OWASP WSTG, SARIF → GitHub, baseline regression, scan-and-fix loop | **Strong** |
-| **(f)** Assessing the effectiveness of measures | Baseline diff, re-scan-to-verify, and `--history` tracking of time-to-fix, ageing, and drift | Partial |
-| **(g)** Cyber hygiene & training | Remediation playbook + secure-defaults guidance (guidance, not a training programme) | Partial |
-| **(h)** Cryptography & encryption | TLS protocol/cipher/certificate audit, HSTS, cookie `Secure` (transport layer only) | Partial |
-| **(i)** HR security, **access control**, asset management | Access control tested: JWT, IDOR/BOLA, OAuth redirect, client-side-auth, trust-boundary mapping | Partial |
-| **(j)** Multi-factor authentication & secure communications | MFA probe (on the roadmap) | Planned |
-
-**Coverage key:** *Strong* = automated technical testing · *Partial* = part of the
-measure · *Evidence* = output feeds the measure, no direct test · *Planned* = on the
-roadmap · *Out of scope* = organisational or physical.
-
-In practice, Penthera today gives you solid automated evidence for the
-secure-development and vulnerability-handling duty (e), which is the technical
-heart of the zorgplicht, plus meaningful coverage of supply chain (d),
-cryptography in transit (h), access control (i), and effectiveness testing (f).
-That is not the whole duty of care, but it is a real, defensible start you can run
-today and re-run on every deploy.
-
-> **Not legal advice, not a certification, not a guarantee of compliance.**
-> Penthera automates the technical-testing part of the duty of care. The
-> directive's organisational duties (governance, risk-management policy,
-> incident-notification processes, supply-chain contracts, staff training) need
-> human process and, where it matters, review by a qualified advisor. For an
-> authoritative reading, consult your national authority (the NCSC in the
-> Netherlands, the CCB and its CyFun framework in Belgium) or a specialised jurist.
-
-Generate this mapping for your own scan with `--framework nis2`. It adds a
-per-run coverage table (which measures *this* scan actually exercised, driven by
-the probes that ran) to the terminal, Markdown, and JSON reports:
-
-```bash
-penthera https://myapp.com --framework nis2 -o reports/scan.json
-```
-
-### Readiness report (clone → report in two commands)
-
-Go further than the mapping: combine the scan with a short offline
-self-assessment (the organisational measures a scanner can't test, like policies,
-backups, training, and MFA) into a full NIS2 readiness report. Every Article 21
-measure is marked `met / partial / gap / n-a`, with proportionality notes, your
-incident-reporting deadlines, and provenance on every piece of evidence.
-
-```bash
-# 1. Create your self-assessment (offline, one-time). Fill in yes | partial | no | na.
-penthera --assessment-init assessment.json
-
-# 2. Scan + self-assessment → readiness report (writes reports/scan-readiness.md)
-penthera https://myapp.com --repo . --readiness --assessment assessment.json -o reports/scan.json
-```
-
-The readiness report is **evidence and self-assessment tooling, not a
-certification**. It is provenance-linked (`source, method, collected_at,
-confidence`) and reproducible, and it lists exactly what only you can attest to.
-Jurisdiction specifics live in [`lib/jurisdictions/nl.json`](../lib/jurisdictions/nl.json) (NL today; BE and
-others are just added config).
-
-### Answer a customer's security questionnaire
-
-The questionnaire blocking your deal, drafted from evidence you already have:
-
-```bash
-# one question per line, pasted from the customer's form
-penthera https://myapp.com --readiness --assessment assessment.json --questionnaire questions.txt
-```
-
-Each question is mapped to the Article 21 measure it belongs to and answered
-from the scan and your self-assessment, with the backing evidence cited.
-Anything Penthera can't map is marked `NEEDS HUMAN INPUT` instead of guessed.
-Review every answer before you send it.
-
-### Policy pack
-
-Generate the proportionate written policies NIS2 expects, pre-filled from your
-readiness gaps and the NL incident deadlines:
-
-```bash
-penthera --policy-pack ./policies --org "Your Company" --readiness --assessment assessment.json
-```
-
-Writes editable Markdown starting points: information security, access control,
-incident response, backup/continuity, acceptable use, supplier security, and
-vulnerability management. **Templates, not legal advice.** Keep them short and
-used. A two-page policy that genuinely exists is what "proportionate" means.
-
-### Incident-report helper
-
-NIS2 has hard reporting deadlines (24h early warning, 72h notification, 1-month
-final report). If something happens, get the timeline and draft reports:
-
-```bash
-penthera --incident-init incident.json   # fill in what happened (set aware_at)
-penthera --incident incident.json        # writes incident-reports.md
-```
-
-It computes your three deadlines from when you became aware, flags anything
-overdue, and drafts the early-warning, notification, and final report against
-the required content, with `NEEDS INPUT` where you still have to fill in facts.
-**These are drafts to help you meet the deadlines, not a substitute for your
-authority's official form.**
-
-### Software bill of materials (SBOM)
-
-Emit a standard CycloneDX SBOM of your dependencies. It's what enterprises
-increasingly require of suppliers, and direct evidence for supply-chain security
-(measure d):
-
-```bash
-penthera --repo . --sbom sbom.cdx.json
-```
-
-Parses `package-lock.json` / `package.json` / `requirements.txt` offline (no
-network), with resolved versions and package URLs (purls).
-
-### Remediation tracking (the audit loop)
-
-Closing findings matters more than finding them. Track them over time:
-time-to-fix, ageing of open items, and what changed since the last scan (evidence
-for measure f, effectiveness):
-
-```bash
-penthera https://myapp.com --history reports/history.json -o reports/scan.json
-```
-
-Each run folds the current findings into a small history keyed by a **stable
-fingerprint** (so a re-worded or re-counted finding isn't mistaken for a new
-one), then reports open vs resolved, median time-to-fix, and ageing buckets.
-Re-run on a cadence to watch the trend.
-
-### Supplier rating (passive)
-
-Assess your suppliers' public security posture for supply-chain risk (measure d):
-
-```bash
-printf 'supplier1.com\nsupplier2.com\n' > suppliers.txt
-penthera --suppliers suppliers.txt
-```
-
-**Strictly passive and public-data-only.** One homepage GET (security headers),
-a TLS handshake (certificate), and public DNS lookups (SPF/DMARC/MX) per domain.
-No endpoint discovery, no auth probes, no intrusive testing. You get a
-red/amber/green rating per supplier. It's a screening aid for your own vendor
-risk assessment, **not** an authorised penetration test of the supplier.
-
-Because the mapping targets the NIS2 directive itself, it applies across the
-national transpositions; jurisdiction-specific profiles (NL, BE) are on the roadmap.