Files

T

Malin fa7c367420 skills: fleet map, default-deny standard, modded-app and vuln-scan skills

- server-fleet-map: add gringo row
- bastille-jail-provisioning: elevate default-deny-outbound to the standard
  for every new jail; reference gringo's live pf.conf
- modded-app-update-pattern: new skill, fork/rebase pattern for locally
  patched apps; uses tailnetatlas on gringo as the concrete example
- dependency-vuln-scanning: new skill, npm audit / pip-audit / osv-scanner
  cadence for deployments and monthly thereafter

2026-08-08 14:01:43 +02:00

3.1 KiB

Raw Blame History

name, description

name	description
dependency-vuln-scanning	Run dependency vulnerability scans on every new deployment/migration and monthly thereafter. Covers Node, Python, and general OS/library scanning.

Dependency Vulnerability Scanning

Dependency vulnerabilities are not a one-time checklist item. They should be scanned on every new deployment or migration into the fleet, and then re-scanned periodically thereafter. For this fleet size, monthly is a reasonable cadence.

When to run

Before marking a new jail/container/app as "live" after provisioning or migration.
Before merging a dependency update.
Monthly, against every actively maintained app and host.

This applies to Docker-host deployments too — a container image is just another artifact with dependencies. Cross-reference the provisioning checklist in skills/bastille-jail-provisioning/SKILL.md and add a vulnerability-scan step before considering any new jail complete.

Tooling by stack

Node.js / npm

npm audit

Use npm audit --audit-level=moderate to filter noise if the project is large. For a CI-friendly exit code, npm audit --audit-level=high will fail only on high/critical findings. Always review the full output at least once.

If the project uses pnpm or yarn, use their equivalents (pnpm audit, yarn audit). The Node ecosystem is common on this fleet — expect to use this one often.

Python

pip-audit

Run inside the project's virtualenv so it sees the same packages the app will actually use. If pip-audit is not installed, add it to the dev tooling in the virtualenv rather than the system Python.

General / OS / multi-ecosystem fallback

osv-scanner -r /path/to/project

osv-scanner is the best general fallback: it understands lockfiles from npm, PyPI, Go, Rust, Maven, and others, and queries the OSV database. Use it when a project mixes ecosystems or when you want a single scanner across a whole host.

What to do with findings

Triage, do not blindly upgrade. A CVE in a dev-only dependency is not the same as one in the runtime path of a public-facing service.
Patch or pin. Prefer a real upstream upgrade. If the upstream fix is not available yet and the risk is real, consider pinning, removing the dependency, or a temporary local patch (tracked via skills/modded-app-update-pattern).
Re-scan after the fix. A green npm audit or pip-audit output is the only proof the finding is resolved.
Record exceptions. If a finding is accepted (e.g. internal-only tool, no reachable attack path), write the justification down in the deployment notes or the issue tracker, not just in someone's memory.

What not to do

Do not treat vulnerability scanning as optional for "internal-only" tools. Internal tools often have the same dependencies and the same CVEs.
Do not run a scan and ignore the output because it is long. Parse it, triage it, file issues for anything that needs follow-up.
Do not rely solely on the language-specific scanner when the project also pulls in OS packages or container base-image packages; add osv-scanner or the image scanner as a second opinion.

3.1 KiB Raw Blame History