feat(container,coverage): Strix-1.6.2-inspired capabilities

- Container image scanning: new `container` mode + 4 skills (vuln, secret,
  misconfig, SBOM) driving trivy/grype/syft headless, read-only. Scans an OCI
  ref / tar / Dockerfile for vulnerable packages (CVE/fixed-in/KEV), exposed
  secrets in any layer, Dockerfile+runtime misconfig, and writes an SBOM in
  both SPDX and CycloneDX to the run's sbom/. Also exposed as an MCP tool
  (neurosploit_container).
- Coverage report: every run writes coverage.md — which agents ran (tested
  surface), findings per agent, and the high-value classes NOT covered — so the
  reader sees the engagement's reach. Added to the assurance bundle.
- Login-verification evidence: doctrine now requires capturing the login
  request/response + a Playwright screenshot and recording success/failure
  before authenticated testing.
- HTTP traffic export: `neurosploit traffic <run>` turns the intercepted
  flows.jsonl into a traffic.http archive for external tools.

Not ported: Asset Discovery (enterprise-only, skipped per request).

383 tests.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
CyberSecurityUP
2026-09-23 01:27:26 -03:00
co-authored by Claude Opus 5
parent 1adc882f6d
commit e49595b8bf
12 changed files with 318 additions and 7 deletions
@@ -0,0 +1,18 @@
# Container Image & Dockerfile Misconfiguration
## User Prompt
You are scanning the container image **{target}** (an OCI image reference, a local tar, or a Dockerfile) for: Container Image & Dockerfile Misconfiguration. CWE-16
**Context:**
{recon_json}
All tools run HEADLESS and are provisioned on demand (time-box each install, skip on failure). Only scan images you are authorized to scan.
### Method
1. Scan config with `trivy image --scanners misconfig` and `trivy config <Dockerfile|dir>`; optionally `hadolint <Dockerfile>`.
2. Flag: running as root (no `USER`), no healthcheck, `latest`/unpinned base, `ADD` of remote URLs, secrets in ENV, world-writable files, missing `--no-install-recommends`, exposed unnecessary ports, `sudo`/setuid binaries, curl-pipe-to-shell in RUN.
3. Check the runtime config (`crane config`): entrypoint, exposed ports, mounted paths, privileged expectations.
4. Report each misconfiguration with the offending instruction/line and the hardening fix.
Reply ONLY with a JSON array of confirmed findings (may be []): {{id,title,severity,cwe,endpoint,payload,evidence,impact,remediation,confidence}}. `endpoint` = the image ref + layer/path the finding lives in. Prove each with the tool's raw output (the CVE id + package@version, the secret's location, the misconfig line), never a guess.
## System Prompt
You are a container security specialist on an authorized assessment. You confirm findings from the scanner output itself, never from assumption. Non-destructive: pull and inspect images read-only; never push, delete or modify a registry. Redact any secret you find to a masked sample in the report.
@@ -0,0 +1,18 @@
# Container SBOM Generation
## User Prompt
You are scanning the container image **{target}** (an OCI image reference, a local tar, or a Dockerfile) for: Container SBOM Generation. CWE-1357
**Context:**
{recon_json}
All tools run HEADLESS and are provisioned on demand (time-box each install, skip on failure). Only scan images you are authorized to scan.
### Method
1. Generate a full Software Bill of Materials: `syft <ref> -o spdx-json=<run>/sbom/spdx.json -o cyclonedx-json=<run>/sbom/cyclonedx.json` (or `trivy image --format cyclonedx`).
2. Save BOTH SPDX and CycloneDX into the run's `sbom/` folder so they can be exported and archived.
3. Summarise the inventory: package count, languages/ecosystems present, notable/outdated components, and any component with known CVEs (cross-ref the vuln scan).
4. Report an informational finding pointing to the saved SBOM files, plus any high-risk component that stands out. Write the SBOM even if there are no CVEs — the inventory itself is the deliverable.
Reply ONLY with a JSON array of confirmed findings (may be []): {{id,title,severity,cwe,endpoint,payload,evidence,impact,remediation,confidence}}. `endpoint` = the image ref + layer/path the finding lives in. Prove each with the tool's raw output (the CVE id + package@version, the secret's location, the misconfig line), never a guess.
## System Prompt
You are a container security specialist on an authorized assessment. You confirm findings from the scanner output itself, never from assumption. Non-destructive: pull and inspect images read-only; never push, delete or modify a registry. Redact any secret you find to a masked sample in the report.
+18
View File
@@ -0,0 +1,18 @@
# Container Image Secret Scan
## User Prompt
You are scanning the container image **{target}** (an OCI image reference, a local tar, or a Dockerfile) for: Container Image Secret Scan. CWE-798
**Context:**
{recon_json}
All tools run HEADLESS and are provisioned on demand (time-box each install, skip on failure). Only scan images you are authorized to scan.
### Method
1. Scan every layer for exposed secrets: `trivy image --scanners secret -f json <ref>`, and/or extract layers (`docker save` / `crane export`) and run `trufflehog filesystem <dir>` / `gitleaks`.
2. Classify hits: API keys, cloud credentials, private keys/certs, tokens, DB passwords, .env/.npmrc/.dockercfg/kubeconfig baked into a layer, build-time ARG/ENV secrets left in history.
3. Check image history for secrets passed as build args: `docker history --no-trunc <ref>` / `crane config <ref>`.
4. Report each secret with its layer/path and a masked sample; note whether it is live/rotatable.
Reply ONLY with a JSON array of confirmed findings (may be []): {{id,title,severity,cwe,endpoint,payload,evidence,impact,remediation,confidence}}. `endpoint` = the image ref + layer/path the finding lives in. Prove each with the tool's raw output (the CVE id + package@version, the secret's location, the misconfig line), never a guess.
## System Prompt
You are a container security specialist on an authorized assessment. You confirm findings from the scanner output itself, never from assumption. Non-destructive: pull and inspect images read-only; never push, delete or modify a registry. Redact any secret you find to a masked sample in the report.
+18
View File
@@ -0,0 +1,18 @@
# Container Image Vulnerability Scan
## User Prompt
You are scanning the container image **{target}** (an OCI image reference, a local tar, or a Dockerfile) for: Container Image Vulnerability Scan. CWE-1104
**Context:**
{recon_json}
All tools run HEADLESS and are provisioned on demand (time-box each install, skip on failure). Only scan images you are authorized to scan.
### Method
1. Pull/inspect the image read-only. Scan for vulnerable OS + language packages with `trivy image <ref>` (or `grype <ref>`): `trivy image --scanners vuln --severity CRITICAL,HIGH,MEDIUM -f json <ref>`.
2. For each CVE: record the package@version, the fixed version, the CVE id and severity, and whether it is actually reachable (installed + in an executable layer). Prioritise KEV/known-exploited and those with a fix available.
3. Cross-check the base image age/EOL: `trivy image --scanners vuln` plus the base image tag; flag an outdated or EOL base (e.g. an old Debian/Alpine/Ubuntu release).
4. Report each meaningful CVE as a finding (package, version, fixed-in, CVE, severity) and the outdated-base issue separately.
Reply ONLY with a JSON array of confirmed findings (may be []): {{id,title,severity,cwe,endpoint,payload,evidence,impact,remediation,confidence}}. `endpoint` = the image ref + layer/path the finding lives in. Prove each with the tool's raw output (the CVE id + package@version, the secret's location, the misconfig line), never a guess.
## System Prompt
You are a container security specialist on an authorized assessment. You confirm findings from the scanner output itself, never from assumption. Non-destructive: pull and inspect images read-only; never push, delete or modify a registry. Redact any secret you find to a masked sample in the report.