penthera 1.1.1 → 1.2.0

package/CHANGELOG.md

@@ -4,6 +4,60 @@ All notable changes to Penthera are documented here. Versioning follows [SemVer]
 
 ## [Unreleased]
 
+## [1.2.0] - 2026-10-19
+
+The first step toward securing the AI toolchain itself: catch AI provider keys,
+harden Penthera's own supply chain, and make CI test what it says it tests. The
+[roadmap](ROADMAP.md) now sets out the AI supply-chain and local agent-loop
+tracks.
+
+### Added
+
+- **AI provider key detection** in repo scans: Anthropic, OpenAI project and
+  service-account keys, OpenRouter, Google (Gemini / Firebase), Groq, Hugging
+  Face, Replicate, xAI, Perplexity, LangSmith, and Pinecone. Jupyter notebooks
+  (`.ipynb`) are now scanned too. A provider key inside an `api_key = "..."`
+  assignment is reported once, under its provider, instead of twice
+- `findSecretsInText()` exported from `lib/whitebox/secrets.js`, so the same
+  rules can run on any text (groundwork for scanning JS bundles)
+- CodeQL and OpenSSF Scorecard workflows, Dependabot for npm and GitHub Actions
+  (with a 7-day cooldown before adopting new releases)
+- CI check that `package.json`, the lockfile, the skill, and both plugin
+  manifests carry the same version
+- Roadmap: AI supply-chain audit (`penthera agents`), a fully local
+  scan → fix → verify → learn loop, and LLM-endpoint probes. Principles now
+  state no telemetry, no auto-push, and no remote learning
+
+### Fixed
+
+- **Modern OpenAI keys were missed.** The old pattern stopped at the hyphen in
+  `sk-proj-...` and `sk-svcacct-...`, so the key format OpenAI has issued since
+  2024 never matched
+- The example scan workflow lived in `.github/workflows/`, so it ran on its
+  weekly cron and failed every Monday. It moved to
+  `docs/examples/github-actions-scan.yml` and now uses `npx penthera@<version>`,
+  so it works when copied into your own repo
+- CI ran only 4 of 24 test files; it now runs the full `npm test`
+- Removed `tests/pentest-static.test.js`, which tested functions defined inside
+  the test file rather than anything Penthera ships
+- `.claude-plugin/plugin.json` still said 1.0.0
+- `SECURITY.md` listed 1.0.x as supported. It now covers 1.2.x and gives response
+  times, scope, and safe-harbor terms
+
+### Changed
+
+- **Node.js 22 or newer is now required.** Node 18 and 20 are end-of-life, and
+  the test toolchain (vitest 5) needs 22. CI runs on Node 22 and 24
+- GitHub Actions are pinned to commit SHAs, and every workflow declares
+  least-privilege `permissions`
+- Releases use npm trusted publishing (OIDC, no stored token) and **staged
+  publishing**: CI stages each version, and it only goes live after a
+  maintainer approves it with 2FA. The workflow also creates the GitHub Release
+- The Docker image runs as the unprivileged `node` user on `node:22-alpine`
+- README reordered so install and quick start come before compliance. The full
+  NIS2 guide moved to [`docs/compliance-nis2.md`](docs/compliance-nis2.md)
+- vitest 3 → 5 (clears 8 dev-only advisories), yaml 2.8 → 2.9
+
 ## [1.1.1] - 2026-08-16
 
 A correctness release. One of these was a live outage: if you are on 1.1.0,
@@ -176,7 +230,7 @@ and generated documents.
   live integration tests report as skipped (not passed) without a running target
 - Corrected the built-in template count (14, not 17) in docs and progress output
 
-## [1.0.0], 2026-06-30
+## [1.0.0] - 2026-06-30
 
 First production-ready release.
 
@@ -201,11 +255,11 @@ First production-ready release.
 
 - URL trailing-slash normalization (double-slash 404 bug)
 
-## [0.2.0], 2026-04
+## [0.2.0] - 2026-04
 
 - Markdown reports, scan profiles, auth tooling, expanded API discovery
 
-## [0.1.x], 2026-04
+## [0.1.x] - 2026-04
 
 - Initial CLI: URL, repo, and machine scan modes
 - Built-in templates, TLS, CORS, SARIF export

package/README.md

@@ -5,9 +5,10 @@
 <br/><br/>
 
 [![npm](https://img.shields.io/npm/v/penthera?color=0000ed)](https://www.npmjs.com/package/penthera)
-![node](https://img.shields.io/badge/node-%E2%89%A518-0000ed)
+![node](https://img.shields.io/badge/node-%E2%89%A522-0000ed)
 ![license](https://img.shields.io/badge/license-MIT-0000ed)
 [![CI](https://github.com/danoszz/penthera/actions/workflows/ci.yml/badge.svg)](https://github.com/danoszz/penthera/actions/workflows/ci.yml)
+[![OpenSSF Scorecard](https://api.scorecard.dev/projects/github.com/danoszz/penthera/badge)](https://scorecard.dev/viewer/?uri=github.com/danoszz/penthera)
 
 <br/>
 
@@ -33,7 +34,8 @@ issues." The agent picks the scan, runs it, and gives you the fixes.
 You shipped something fast: vibecoded, AI-assisted, already live. The same models
 that helped you build it also make it easy for someone to probe it. Exposed API
 routes, missing security headers, weak auth, a hardcoded key in the repo. These
-are the common mistakes that get apps broken into.
+are the common mistakes that get apps broken into. An AI provider key in the
+frontend bundle is the newest and most expensive of them.
 
 Penthera is the check you run before you launch. Ask your agent to "scan my app
 for security issues" and it runs an authorized, non-destructive scan, then lists
@@ -114,7 +116,7 @@ Prefer the terminal? Run `penthera` with no arguments for a guided wizard.
 | Mode | Command | Coverage |
 |------|---------|----------|
 | **URL scan** | `penthera https://example.com` | TLS, fingerprinting, endpoint discovery, templates, CORS, cookies, JS CVEs, param discovery, OpenAPI/FastAPI probes, security headers, auth hardening |
-| **Repo scan** | `penthera --repo ./my-app` | API route discovery (Next.js, Express, Hono, Fastify), trust-boundary mapping, hardcoded-secret scanning |
+| **Repo scan** | `penthera --repo ./my-app` | API route discovery (Next.js, Express, Hono, Fastify), trust-boundary mapping, hardcoded-secret scanning (including Anthropic, OpenAI, Gemini, Groq, Hugging Face and other AI provider keys) |
 | **Combined** | `penthera https://staging.app --repo .` | Black-box and white-box in one run |
 | **Interactive** | `penthera` *(no args)* | Guided wizard (URL plus optional repo scan, Markdown report) |
 | **Machine audit** | `penthera --machine` | macOS checks (keyloggers, persistence, rootkits) |
@@ -157,245 +159,6 @@ Findings map to the [OWASP Web Security Testing Guide](docs/owasp-wstg-coverage.
 
 ---
 
-## Compliance: NIS2 and the cyberwetgeving
-
-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` (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.
-
----
-
-## Ethical use & authorization
-
-Penthera sends HTTP requests to the targets you give it. Some modes (`--deep`,
-`--fuzz`, `--all`) send attack payloads designed to find vulnerabilities. Use it
-responsibly.
-
-**You may use Penthera when:**
-
-- You **own** the target (your app, your server, your project).
-- You have **written authorization** from the system owner (email, ticket, signed scope).
-- You scan **localhost** or private lab environments you control.
-- You use it for **defensive security**: research, coursework, CI hardening, pre-release audits.
-
-**You must not use Penthera to:**
-
-- Scan systems you do not own or lack explicit permission to test.
-- Probe government, healthcare, financial, or third-party production systems without authorization.
-- Exfiltrate data, disrupt services, or bypass access controls.
-- Use findings to attack, extort, or harm anyone.
-
-> Before scanning any URL that is not localhost, confirm you have permission.
-> **When in doubt, do not scan.**
-
-Unauthorized security testing may violate computer-misuse laws (for example the US
-CFAA, the UK Computer Misuse Act, and EU national equivalents) and can result in
-criminal prosecution, civil liability, IP blocking, account termination, and
-academic or professional penalties.
-
----
-
-## Disclaimer
-
-Penthera is provided for legitimate security research and defensive testing of
-systems you own or are authorized to test, and for that purpose only.
-
-- It is a research and self-assessment tool. Scan your own apps to find and fix
-  weaknesses before attackers do.
-- The same capabilities that harden a system can cause harm if pointed at someone
-  else's. Use it carefully and lawfully.
-- The author does not condone unauthorized or malicious use, and accepts no
-  liability for any damage, loss, or legal consequence arising from use or misuse
-  of this software.
-- The software is provided "as is", without warranty of any kind. See [LICENSE](LICENSE) (MIT).
-- You are solely responsible for ensuring every scan you run is authorized and
-  legal in your jurisdiction.
-
-By using Penthera you accept these terms.
-
----
-
-## Install
-
-The [one-line installer](#run-it) is the fastest path. To set it up manually:
-
-```bash
-git clone https://github.com/danoszz/penthera.git
-cd penthera
-npm install
-npm link            # exposes `penthera` and `penthera-scan` globally
-penthera --version
-```
-
-Requirements: Node.js 18+ and npm. Optional: nuclei-templates for `--nuclei`, and
-Docker. To run it in a container:
-
-```bash
-docker build -t penthera .
-docker run --rm penthera https://your-app.example
-```
-
----
-
 ## Quick start
 
 ```bash
@@ -510,19 +273,100 @@ Fixes come from a [remediation playbook](skills/penthera/references/remediation.
 
 ---
 
+## Compliance: NIS2 and the cyberwetgeving
+
+Shipping in the EU? NIS2 (the Cyberbeveiligingswet in the Netherlands, the
+NIS2-wet in Belgium) puts a duty of care on in-scope organisations. Penthera
+turns the technical, testable part of that duty into repeatable evidence, and
+helps with the paperwork around it. Offline, no accounts.
+
+| Command | What you get |
+|---------|--------------|
+| `--framework nis2` | Per-run Article 21(2) coverage table in every report |
+| `--readiness --assessment a.json` | Full readiness report: every measure marked met / partial / gap |
+| `--questionnaire questions.txt` | Customer security questionnaire drafted from your evidence |
+| `--policy-pack ./policies` | Proportionate policy templates, prefilled from your gaps |
+| `--incident incident.json` | 24h / 72h / 1-month incident report drafts and deadlines |
+| `--sbom sbom.cdx.json` | CycloneDX software bill of materials |
+| `--history history.json` | Time-to-fix, ageing, and drift across scans |
+| `--suppliers suppliers.txt` | Passive red/amber/green rating of your suppliers |
+
+**Full guide, the measure-by-measure coverage table, and the limits:**
+[docs/compliance-nis2.md](docs/compliance-nis2.md).
+
+> Readiness tooling, not a certification and not legal advice.
+
+---
+
 ## CI integration
 
 ```yaml
 # Scan a staging URL on a schedule and upload results to GitHub Security.
-# Set the PENTEST_STAGING_URL secret to enable. Full example: .github/workflows/scan.yml
-- run: npx penthera "$PENTEST_URL" --profile standard --sarif reports/scan.sarif
-- uses: github/codeql-action/upload-sarif@v3
+- run: npx penthera@1.2.0 "$PENTEST_URL" --profile standard --sarif reports/scan.sarif
+- uses: github/codeql-action/upload-sarif@v4
   with:
     sarif_file: reports/scan.sarif
 ```
 
-The repo's own CI (`.github/workflows/ci.yml`) runs the offline suites on Node 18,
-20, and 22, and self-scans a mock vulnerable API on every push.
+Copy the full workflow from
+[`docs/examples/github-actions-scan.yml`](docs/examples/github-actions-scan.yml)
+into your app's repo. Pin the Penthera version so a scheduled run never picks up
+code you have not reviewed.
+
+Penthera's own CI runs the full test suite on Node 22 and 24, self-scans a mock
+vulnerable API on every push, and runs CodeQL and OpenSSF Scorecard.
+
+---
+
+## Ethical use & authorization
+
+Penthera sends HTTP requests to the targets you give it. Some modes (`--deep`,
+`--fuzz`, `--all`) send attack payloads designed to find vulnerabilities. Use it
+responsibly.
+
+**You may use Penthera when:**
+
+- You **own** the target (your app, your server, your project).
+- You have **written authorization** from the system owner (email, ticket, signed scope).
+- You scan **localhost** or private lab environments you control.
+- You use it for **defensive security**: research, coursework, CI hardening, pre-release audits.
+
+**You must not use Penthera to:**
+
+- Scan systems you do not own or lack explicit permission to test.
+- Probe government, healthcare, financial, or third-party production systems without authorization.
+- Exfiltrate data, disrupt services, or bypass access controls.
+- Use findings to attack, extort, or harm anyone.
+
+> Before scanning any URL that is not localhost, confirm you have permission.
+> **When in doubt, do not scan.**
+
+Unauthorized security testing may violate computer-misuse laws (for example the US
+CFAA, the UK Computer Misuse Act, and EU national equivalents) and can result in
+criminal prosecution, civil liability, IP blocking, account termination, and
+academic or professional penalties.
+
+---
+
+## Install
+
+The [one-line installer](#run-it) is the fastest path. To set it up manually:
+
+```bash
+git clone https://github.com/danoszz/penthera.git
+cd penthera
+npm install
+npm link            # exposes `penthera` and `penthera-scan` globally
+penthera --version
+```
+
+Requirements: Node.js 22+ and npm. Optional: nuclei-templates for `--nuclei`, and
+Docker. To run it in a container:
+
+```bash
+docker build -t penthera .
+docker run --rm penthera https://your-app.example
+```
 
 ---
 
@@ -547,9 +391,8 @@ npm run pentest:mock     # offline tests against a local mock vuln API
 npm run mock-server      # start the mock API on port 8765
 ```
 
-See the [roadmap](ROADMAP.md) for what is next and what is deliberately not planned.
-
-See the [roadmap](ROADMAP.md) for what is next and what is deliberately not
+See the [roadmap](ROADMAP.md) for what is next, including auditing the skills,
+MCP servers, and plugins in your AI toolchain, and what is deliberately not
 planned.
 
 See [CONTRIBUTING.md](CONTRIBUTING.md) for the project layout, how to add a probe
@@ -559,7 +402,7 @@ or template, the test matrix, and the release and publishing checklist.
 
 ## Status
 
-**v1.0, production-ready.** URL, repo, and machine scanning, scan profiles,
+**v1.2, production-ready.** URL, repo, and machine scanning, NIS2 readiness tooling, scan profiles,
 Markdown, JSON, and SARIF reports, session-aware auth, JWT, IDOR, OAuth, and
 header probes, adaptive knowledge-graph probing, a plugins and templates API,
 Docker, CI, and the Agent Skill are all shipped. See the [CHANGELOG](CHANGELOG.md)
@@ -594,6 +437,26 @@ You are responsible for ensuring you are authorized to scan any target. See [Eth
 
 ---
 
+## Disclaimer
+
+Penthera is provided for legitimate security research and defensive testing of
+systems you own or are authorized to test, and for that purpose only.
+
+- It is a research and self-assessment tool. Scan your own apps to find and fix
+  weaknesses before attackers do.
+- The same capabilities that harden a system can cause harm if pointed at someone
+  else's. Use it carefully and lawfully.
+- The author does not condone unauthorized or malicious use, and accepts no
+  liability for any damage, loss, or legal consequence arising from use or misuse
+  of this software.
+- The software is provided "as is", without warranty of any kind. See [LICENSE](LICENSE) (MIT).
+- You are solely responsible for ensuring every scan you run is authorized and
+  legal in your jurisdiction.
+
+By using Penthera you accept these terms.
+
+---
+
 ## License & disclosure
 
 MIT. See [LICENSE](LICENSE). Report vulnerabilities in Penthera itself via

package/SECURITY.md

@@ -2,21 +2,43 @@
 
 ## Supported versions
 
+Security fixes land on the latest minor release only. Upgrade to get them.
+
 | Version | Supported |
 | ------- | --------- |
-| 1.0.x   | Yes       |
-| < 1.0   | No        |
+| 1.2.x   | Yes       |
+| < 1.2   | No        |
 
 ## Reporting a vulnerability
 
 If you find a security issue in **Penthera itself** (not a finding produced by
 scanning a target), please report it privately:
 
-1. Open a [GitHub Security Advisory](https://github.com/danoszz/penthera/security/advisories/new), or
-2. Email the repository owner with a clear description and reproduction steps.
+1. Open a [GitHub Security Advisory](https://github.com/danoszz/penthera/security/advisories/new)
+   (preferred: it keeps the report private and lets us credit you), or
+2. Email the maintainer via the address on the [GitHub profile](https://github.com/danoszz)
+   with a clear description and reproduction steps.
+
+Please do **not** open public issues for undisclosed vulnerabilities.
+
+**What to expect.** Penthera is maintained part-time, but security reports come
+first:
+
+- Acknowledgement within 3 working days.
+- An initial assessment (accepted, needs more info, or out of scope) within 10
+  working days.
+- A fix or mitigation for accepted issues as fast as severity warrants, followed
+  by a release, a GitHub advisory, and credit to you unless you prefer otherwise.
+
+**In scope:** the CLI, the scanner engine (`lib/`, `src/`), the Agent Skill
+(`skills/penthera/`), the installer (`install.sh`), and the published npm package
+and its build pipeline. Examples: code execution from a malicious scan target or
+repo, a skill instruction that bypasses the authorization gate, a supply-chain
+weakness in our release workflow.
 
-Please do **not** open public issues for undisclosed vulnerabilities. We aim to
-acknowledge reports within a few days.
+**Safe harbor.** Good-faith research on Penthera's own code, done on your own
+machine, is welcome and we will not pursue action against it. This does not
+cover scanning third-party systems: the authorization rules below still apply.
 
 ## Responsible use
 

package/docs/compliance-nis2.md

@@ -0,0 +1,166 @@
+# Compliance: NIS2 and the cyberwetgeving
+
+Back to the [README](../README.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.

package/docs/examples/github-actions-scan.yml

@@ -0,0 +1,55 @@
+# Example: scan your staging URL with Penthera on a schedule.
+#
+# Copy this file into YOUR app's repo as `.github/workflows/penthera.yml` and add
+# a `PENTEST_STAGING_URL` repository secret. Only point it at a URL you own or are
+# authorized to test. Findings appear under Security > Code scanning.
+#
+# Pin the Penthera version (and, ideally, the actions below to commit SHAs) so a
+# scheduled run never picks up code you have not reviewed.
+
+name: Penthera security scan
+
+on:
+  workflow_dispatch:
+  schedule:
+    - cron: "0 6 * * 1" # weekly, Monday 06:00 UTC
+
+permissions:
+  contents: read
+
+jobs:
+  penthera:
+    runs-on: ubuntu-latest
+    permissions:
+      contents: read
+      security-events: write
+    steps:
+      - uses: actions/setup-node@v6
+        with:
+          node-version: 22
+
+      - name: Scan staging URL
+        env:
+          PENTEST_URL: ${{ secrets.PENTEST_STAGING_URL }}
+        run: |
+          mkdir -p reports
+          set +e
+          npx --yes penthera@1.2.0 "$PENTEST_URL" \
+            --profile standard \
+            -o reports/scan.json \
+            --sarif reports/scan.sarif
+          code=$?
+          set -e
+          # Exit 1 = critical or high findings (reported via SARIF); only 2 (scan error) fails the job.
+          if [ "$code" -eq 2 ]; then exit 2; fi
+
+      - uses: github/codeql-action/upload-sarif@v4
+        if: always()
+        with:
+          sarif_file: reports/scan.sarif
+
+      - uses: actions/upload-artifact@v7
+        if: always()
+        with:
+          name: penthera-reports
+          path: reports/

package/docs/index.md

@@ -1,6 +1,6 @@
 # Penthera documentation
 
-Lightweight security scanner for developers, scan live URLs, local repos, or macOS machines from the CLI.
+Security scanner for developers: scan live URLs, local repos, or macOS machines from your AI agent or the CLI.
 
 ## Getting started
 
@@ -33,8 +33,9 @@ Lightweight security scanner for developers, scan live URLs, local repos, or mac
 | Topic | Link |
 |-------|------|
 | OWASP WSTG mapping | [owasp-wstg-coverage.md](./owasp-wstg-coverage.md) |
-| GitHub Actions CI | `.github/workflows/ci.yml` (mock scan + SARIF) |
-| Staging scans | `.github/workflows/scan.yml`, set `PENTEST_STAGING_URL` secret |
+| NIS2 compliance guide | [compliance-nis2.md](./compliance-nis2.md) |
+| Scan your app in GitHub Actions | [examples/github-actions-scan.yml](./examples/github-actions-scan.yml), set `PENTEST_STAGING_URL` |
+| Penthera's own CI | `.github/workflows/ci.yml` (full tests + mock scan), `codeql.yml`, `scorecard.yml` |
 | Docker | `docker build -t penthera . && docker run penthera https://localhost:3000` |
 
 ## Agent skill

package/lib/whitebox/secrets.js

@@ -21,7 +21,23 @@ const TEST_VALUE = /\b(?:placeholder|example|changeme|dummy|sample|redacted|inva
 const SECRET_PATTERNS = [
   { name: "AWS access key", pattern: /AKIA[0-9A-Z]{16}/, severity: "critical" },
   { name: "GitHub token", pattern: /ghp_[a-zA-Z0-9]{36,}/, severity: "critical" },
-  { name: "OpenAI API key", pattern: /sk-[a-zA-Z0-9]{20,}/, severity: "critical" },
+  // AI provider keys. Vibecoded apps leak these more than any other credential,
+  // often via a NEXT_PUBLIC_/VITE_ variable or a committed notebook. Specific
+  // prefixes come first so a key is reported under its real provider.
+  { name: "Anthropic API key", pattern: /sk-ant-(?:api|admin)\d{2}-[A-Za-z0-9_-]{32,}/, severity: "critical" },
+  { name: "OpenRouter API key", pattern: /sk-or-v1-[a-f0-9]{64}/, severity: "critical" },
+  { name: "OpenAI API key", pattern: /sk-(?:proj|svcacct|admin)-[A-Za-z0-9_-]{20,}/, severity: "critical" },
+  { name: "OpenAI API key (legacy format)", pattern: /sk-[a-zA-Z0-9]{20,}/, severity: "critical" },
+  // AIza keys are also Firebase web keys, which are public by design, so this
+  // is high rather than critical: it matters if the key has Gemini/Vertex access.
+  { name: "Google API key (Gemini / Firebase / Maps)", pattern: /AIza[0-9A-Za-z_-]{35}/, severity: "high" },
+  { name: "Groq API key", pattern: /gsk_[A-Za-z0-9]{48,}/, severity: "critical" },
+  { name: "Hugging Face token", pattern: /hf_[A-Za-z0-9]{34,}/, severity: "critical" },
+  { name: "Replicate API token", pattern: /r8_[A-Za-z0-9]{37,}/, severity: "critical" },
+  { name: "xAI API key", pattern: /xai-[A-Za-z0-9]{70,}/, severity: "critical" },
+  { name: "Perplexity API key", pattern: /pplx-[A-Za-z0-9]{40,}/, severity: "critical" },
+  { name: "LangSmith API key", pattern: /lsv2_(?:pt|sk)_[a-f0-9]{32}_[a-f0-9]{10}/, severity: "high" },
+  { name: "Pinecone API key", pattern: /pcsk_[A-Za-z0-9_]{50,}/, severity: "high" },
   { name: "Stripe secret key", pattern: /sk_live_[a-zA-Z0-9]{20,}/, severity: "critical" },
   {
     name: "Generic API key assignment",
@@ -35,8 +51,8 @@ const SECRET_PATTERNS = [
     severity: "high",
     skipIf: TEST_VALUE,
   },
-  { name: "Private key block", pattern: /-----BEGIN (?:RSA |EC |OPENSSH )?PRIVATE KEY-----/, severity: "critical" },
   { name: "GCP/Firebase service account", pattern: /"private_key"\s*:\s*"-----BEGIN/, severity: "critical" },
+  { name: "Private key block", pattern: /-----BEGIN (?:RSA |EC |OPENSSH )?PRIVATE KEY-----/, severity: "critical" },
   {
     name: "JWT secret assignment",
     pattern: /(?:jwt[_-]?secret|session[_-]?secret)\s*[:=]\s*['"][^'"\s]{8,}['"]/i,
@@ -48,6 +64,7 @@ const SECRET_PATTERNS = [
 const SCAN_EXTENSIONS = new Set([
   ".js", ".ts", ".jsx", ".tsx", ".mjs", ".cjs", ".py", ".rb", ".go", ".java",
   ".env", ".yaml", ".yml", ".json", ".toml", ".cfg", ".ini", ".sh",
+  ".ipynb", // notebooks are a classic place for a pasted provider key
 ]);
 
 function walkFiles(dir, files = []) {
@@ -69,9 +86,34 @@ function maskMatch(match) {
   return match.length <= 8 ? "***" : match.slice(0, 4) + "…" + match.slice(-4);
 }
 
+/**
+ * Find secrets in a string of text (a source file, a JS bundle, a config).
+ * Returns one hit per rule: `{ name, severity, match }`, with the raw match so
+ * callers decide how to mask it. At most one rule fires per provider key: once a
+ * specific AI-provider rule matches a span, broader rules skip that span.
+ */
+export function findSecretsInText(content) {
+  const hits = [];
+  const claimed = [];
+  for (const rule of SECRET_PATTERNS) {
+    const match = content.match(rule.pattern);
+    if (!match) continue;
+    // For assignment-style rules, test the placeholder/dummy filter against
+    // the assigned value only (not the whole `key = "value"` match), so a
+    // variable named e.g. `testToken` can't mask a real secret.
+    const value = (match[0].match(/['"]([^'"]+)['"]/) || [, match[0]])[1];
+    if (rule.skipIf && rule.skipIf.test(value)) continue;
+    const start = match.index;
+    const end = start + match[0].length;
+    if (claimed.some(([a, b]) => start < b && end > a)) continue;
+    claimed.push([start, end]);
+    hits.push({ name: rule.name, severity: rule.severity, match: match[0] });
+  }
+  return hits;
+}
+
 export function scanSecrets(repoPath) {
   const findings = [];
-  const seen = new Set();
 
   for (const filePath of walkFiles(repoPath)) {
     let content;
@@ -83,23 +125,11 @@ export function scanSecrets(repoPath) {
 
     const rel = relative(repoPath, filePath);
 
-    for (const rule of SECRET_PATTERNS) {
-      const match = content.match(rule.pattern);
-      if (!match) continue;
-      // For assignment-style rules, test the placeholder/dummy filter against
-      // the assigned value only (not the whole `key = "value"` match), so a
-      // variable named e.g. `testToken` can't mask a real secret.
-      const value = (match[0].match(/['"]([^'"]+)['"]/) || [, match[0]])[1];
-      if (rule.skipIf && rule.skipIf.test(value)) continue;
-
-      const key = `${rel}::${rule.name}`;
-      if (seen.has(key)) continue;
-      seen.add(key);
-
+    for (const hit of findSecretsInText(content)) {
       findings.push({
-        severity: rule.severity,
-        title: `${rule.name} in source`,
-        description: `Possible secret in \`${rel}\`: \`${maskMatch(match[0])}\``,
+        severity: hit.severity,
+        title: `${hit.name} in source`,
+        description: `Possible secret in \`${rel}\`: \`${maskMatch(hit.match)}\``,
         url: rel,
         category: "secrets",
         source: "secret-scan",

package/package.json

@@ -1,8 +1,8 @@
 {
   "name": "penthera",
-  "version": "1.1.1",
+  "version": "1.2.0",
   "type": "module",
-  "description": "Lightweight security scanner for web apps — scan URLs or repos from the CLI",
+  "description": "Security scanner for web apps and AI-built code: scan URLs and repos from Claude Code, Cursor or the CLI. OWASP-mapped, SARIF output, NIS2 evidence. Authorized testing only.",
   "repository": {
     "type": "git",
     "url": "git+https://github.com/danoszz/penthera.git"
@@ -21,7 +21,6 @@
     "lib",
     "skills",
     "docs",
-    "scripts/package-skill.sh",
     "pentest.config.example.js",
     "CHANGELOG.md",
     "LICENSE",
@@ -34,7 +33,7 @@
     "./wstg": "./lib/owasp-wstg.js"
   },
   "engines": {
-    "node": ">=18"
+    "node": ">=22"
   },
   "scripts": {
     "test": "vitest run --reporter=verbose",
@@ -42,7 +41,6 @@
     "scan:full": "node bin/scan.js",
     "pentest": "vitest run --reporter=verbose",
     "pentest:watch": "vitest --reporter=verbose",
-    "pentest:static": "vitest run tests/pentest-static.test.js --reporter=verbose",
     "pentest:live": "vitest run tests/pentest-live.test.js --reporter=verbose",
     "pentest:adaptive": "vitest run tests/pentest-adaptive.test.js --reporter=verbose",
     "pentest:recon": "vitest run tests/pentest-recon.test.js --reporter=verbose",
@@ -68,9 +66,9 @@
   ],
   "license": "MIT",
   "devDependencies": {
-    "vitest": "^3.1.1"
+    "vitest": "^5.0.5"
   },
   "dependencies": {
-    "yaml": "^2.8.3"
+    "yaml": "^2.9.1"
   }
 }

package/skills/penthera/SKILL.md

@@ -9,11 +9,11 @@ description: >
   against a baseline; or find hardcoded secrets before deploy. Do NOT use for targets
   without explicit authorization.
 license: MIT
-compatibility: Node.js 18+, network access to target, Penthera CLI (npm link or node bin/penthera.js from repo). macOS only for --machine.
+compatibility: Node.js 22+, network access to target, Penthera CLI (npm link or node bin/penthera.js from repo). macOS only for --machine.
 allowed-tools: "Bash(node:*) Bash(npm:*) Bash(penthera:*) Read Write Edit"
 metadata:
   author: danoszz
-  version: 1.1.1
+  version: 1.2.0
   category: security
 ---
 

package/skills/penthera/references/output-and-ci.md

@@ -44,59 +44,21 @@ Output includes: new findings count, resolved count, unchanged count. Use for we
 
 ## GitHub Actions
 
-**Penthera CI** (`.github/workflows/ci.yml`) runs on every push:
+**Penthera's own CI** (`.github/workflows/ci.yml`) runs on every push and PR:
 
-1. Unit + mock server tests
-2. Skill preflight check
-3. Scan against the local mock API → JSON + SARIF
-4. `validate-report.mjs` on the JSON output
-5. SARIF upload to GitHub Security tab
+1. The full test suite (`npm test`) on Node 22 and 24
+2. A scan of the deliberately vulnerable mock API, producing JSON + SARIF
+3. `validate-report.mjs` on the JSON output, plus the skill preflight
 
-For **your staging URL**, copy `.github/workflows/scan.example.yml` to `scan.yml`:
+The mock-server SARIF is kept as a build artifact, not uploaded to code scanning,
+because those findings are about the test fixture, not the repo.
 
-```yaml
-name: Security Scan
-
-on:
-  workflow_dispatch:
-  schedule:
-    - cron: "0 6 * * 1"
-
-jobs:
-  penthera:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-
-      - uses: actions/setup-node@v4
-        with:
-          node-version: 20
-          cache: npm
-
-      - run: npm ci
-
-      - name: Scan staging URL
-        env:
-          PENTEST_URL: ${{ secrets.PENTEST_STAGING_URL }}
-        run: |
-          node bin/penthera.js "$PENTEST_URL" \
-            --profile standard \
-            -o reports/scan.json \
-            --sarif reports/scan.sarif
-
-      - uses: github/codeql-action/upload-sarif@v3
-        if: always()
-        with:
-          sarif_file: reports/scan.sarif
-
-      - uses: actions/upload-artifact@v4
-        if: always()
-        with:
-          name: penthera-reports
-          path: reports/
-```
-
-Store `PENTEST_STAGING_URL` as a repository secret.
+**For your own staging URL**, copy
+[`docs/examples/github-actions-scan.yml`](https://github.com/danoszz/penthera/blob/main/docs/examples/github-actions-scan.yml)
+into your app's repo as `.github/workflows/penthera.yml` and add a
+`PENTEST_STAGING_URL` repository secret. It runs `npx penthera@<version>` on a
+weekly schedule and uploads SARIF to your Security tab. Pin the version so a
+scheduled run never picks up code you have not reviewed.
 
 ## Agent reporting workflow
 

package/skills/penthera/references/troubleshooting.md

@@ -21,7 +21,7 @@ penthera https://myapp.com --verbose --timeout 30000
 
 **Symptoms:** `node: command not found` or engine error
 
-**Solution:** Install Node.js 18+ from [nodejs.org](https://nodejs.org/). Verify:
+**Solution:** Install Node.js 22+ from [nodejs.org](https://nodejs.org/). Verify:
 
 ```bash
 node -v   # should be v18.x or higher

package/skills/penthera/scripts/preflight.sh

@@ -20,14 +20,14 @@ ok() {
   echo "preflight: OK: $*"
 }
 
-# Node.js 18+
+# Node.js 22+
 if ! command -v node >/dev/null 2>&1; then
-  fail "Node.js not found. Install Node.js 18+ from https://nodejs.org/"
+  fail "Node.js not found. Install Node.js 22+ from https://nodejs.org/"
 fi
 
 NODE_MAJOR=$(node -e "process.stdout.write(String(process.version).replace(/^v/, '').split('.')[0])")
-if [ "$NODE_MAJOR" -lt 18 ]; then
-  fail "Node.js $(node -v) is too old. Requires Node.js 18+."
+if [ "$NODE_MAJOR" -lt 22 ]; then
+  fail "Node.js $(node -v) is too old. Requires Node.js 22+."
 fi
 ok "Node.js $(node -v)"
 

package/scripts/package-skill.sh

@@ -1,16 +0,0 @@
-#!/usr/bin/env bash
-# Package the Agent Skill for Claude.ai upload or GitHub Releases.
-set -euo pipefail
-
-ROOT="$(cd "$(dirname "$0")/.." && pwd)"
-OUT="$ROOT/dist"
-ZIP="$OUT/penthera-skill.zip"
-
-mkdir -p "$OUT"
-rm -f "$ZIP"
-
-cd "$ROOT/skills"
-zip -r "$ZIP" penthera/ -x "*.DS_Store"
-
-echo "Created $ZIP"
-ls -lh "$ZIP"