Cloud and infrastructure

Pencheff's ASM engine does continuous passive discovery across your organisation's public surface and alerts on new exposures. No active scanning — strictly OSINT + certificate-transparency + vendor APIs.

One-call orchestration: scan_asm

scan_asm is the unified entry point used by the swarm. It runs passive discovery, certificate-transparency watch, and snapshot/diff in one call, and persists results to the same inventory.

scan_asm(
  session_id=sid,
  org='acme-inc',
  root_domain='acme.com',
  modules=['discover', 'cert_watch', 'change_detection']  # optional, defaults to all
)
→ {
    discover: { subdomains: 47, certs: 180 },
    cert_watch: { recent_certs: 5, findings_added: 5 },
    change_detection: { new_assets: 3 },
  }

Module	What it runs
discover	subfinder + crt.sh passive subdomain enumeration
cert_watch	Certificate Transparency log watch (new issuances in last 7 days)
change_detection	Snapshot vs. last run; emits INFO findings for new assets
asset_inventory	Lists all known assets (subdomain, IP, port, cert, URL)

The granular tools below (asm_discover, asm_cert_watch, asm_diff, asm_list_assets) remain available — scan_asm is the single call you use from automation or the agent swarm.

What it discovers

Source	Signal
subfinder	Passive subdomain enumeration (when installed)
crt.sh	Subdomains from Certificate Transparency logs + cert metadata
Shodan (optional)	Exposed services, banners (requires SHODAN_API_KEY)
Censys (optional)	Certs + services (requires Censys creds)

Run a discovery

asm_discover(session_id=sid, org='acme-inc', root_domain='acme.com')
→ { subdomains: 47, certs: 180, shodan_hosts: 12 }

The result is persisted to ~/.pencheff/asm_inventory.db (CLI) or the SaaS assets table (dashboard).

See what's in your inventory

asm_list_assets(session_id=sid, org='acme-inc', asset_type='subdomain')
→ [
    { type: 'subdomain', value: 'api.acme.com', first_seen: ..., last_seen: ... },
    { type: 'subdomain', value: 'staging.acme.com', ... },
    …
  ]

On the dashboard, /assets shows all types (domain, subdomain, IP, port, cert, URL) with filter tabs and diff views.

Change detection

asm_diff(session_id=sid, org='acme-inc')
→ { new_assets: 3, findings_added: 3 }

Each new asset becomes an INFO-severity Finding so your normal integrations (Slack, PagerDuty, etc.) can route it based on severity.

Certificate Transparency watch

asm_cert_watch(session_id=sid, domain='acme.com')
→ { recent_certs: 5, findings_added: 5 }

Flags certs issued in the last 7 days — useful for spotting unauthorised issuances or subdomain takeovers.

Scheduling

The dashboard's /schedules UI lets you run ASM on a cron schedule. Pair it with an integration to alert on every change:

1. Create a Slack integration with severity_filter = info
2. Create a Schedule with profile asm, cron 0 2 * * *
3. The Celery Beat dispatcher fires every minute and enqueues due jobs

Pairing with scans

Pencheff treats ASM assets as first-class scan targets. You can feed the inventory straight into a scan:

# Every subdomain gets a quick cicd pass
for asset in asm_list_assets(org='acme-inc', asset_type='subdomain'):
    pentest_init(target_url=f"https://{asset.value}", profile='cicd')
    …

The dashboard exposes the same as a Scan every asset bulk action.

Pencheff ships a host vulnerability assessment engine that complements the web DAST with host-level CVE discovery, unauthenticated-service misconfig probes, authenticated package audits, and industrial-protocol exposure checks.

Modules

Module	What it does
scan_host_vulns	Pencheff service detection → derive package/version → OSV CVE lookup → EPSS + KEV enrichment.
scan_network_misconfig	Unauthenticated probes for Redis, MongoDB, Elasticsearch, Memcached, Docker-over-TCP, MySQL, PostgreSQL, SNMP.
scan_authenticated_host	SSH (paramiko) / WinRM / SMB package enumeration → per-package CVE lookup. Use for patch-management visibility.
scan_industrial_protocols	Modbus, BACnet, Siemens S7, EtherNet/IP, DNP3 exposure check. Passive exposure check only; never sends protocol commands.
refresh_cve_feed	Pulls CISA KEV + EPSS CSV into the local SQLite cache.

Example

Host CVE scan:

scan_host_vulns(session_id=sid, host='10.0.0.42', ports='top-1000')
→ { findings_added: 12, total: 12 }

Unauthenticated misconfig pass:

scan_network_misconfig(session_id=sid, host='10.0.0.42')
→ {
    findings_added: 3,
    findings: [
      "Redis exposed without authentication",
      "MongoDB accessible without authentication",
      "Elasticsearch exposed without authentication"
    ]
  }

Authenticated host scan with an SSH key:

# First load credentials
pentest_configure(session_id=sid, updates={
  "credentials": {
    "name": "infra",
    "username": "deploy",
    "custom_headers": { "ssh_key_path": "/home/me/.ssh/id_ed25519" }
  }
})

# Then run the authenticated scan
scan_authenticated_host(
  session_id=sid,
  host='10.0.0.42',
  protocol='ssh',
  credentials_ref='infra'
)
→ {
    findings_added: 18,
    os_name: "Ubuntu",
    package_count: 1247
  }

How It Fits With Dedicated Network Scanners

Feature	Dedicated network scanners	Pencheff Network VA
Unauthenticated service probes	Large feed-backed rule libraries	Targeted probes for Redis/Mongo/Elastic/Memcached/Docker/MySQL/PG/SNMP + optional network templates
Authenticated scans	SSH/SMB-based patch audit	SSH (paramiko) / WinRM (pywinrm) / SMB (impacket optional)
CVE feed	Tool-specific CVE and advisory feeds	OSV.dev + CISA KEV + EPSS (daily refresh)
Reporting	Tool-specific report formats	Unified Finding model with CVSS + compliance mapping
Integration	Standalone	Plugs into the same session as DAST + SCA + IaC

Dedicated network-scanning platforms remain the right fit for large-scale pure-network scans over millions of assets; Pencheff Network VA is designed to be part of a mixed-surface pentest where you want web, network, SCA, and IaC findings in one session.

Compliance mapping

Network VA findings map to:

• OWASP A06 — Vulnerable & Outdated Components
• A05 — Security Misconfiguration
• PCI-DSS 2.2, 6.2, 11.3
• NIST 800-53 SI-2, CM-6, RA-5
• SOC 2 CC7.1
• ISO 27001 A.8.8, A.8.9, A.5.32
• HIPAA 164.308(a)(8)

What's next

• EPSS & KEV enrichment
• ASM: find hosts before you scan them

The repo scanner runs Trivy IaC and Checkov in parallel against Terraform, CloudFormation, Helm, Kubernetes manifests, and Dockerfiles. This tutorial walks through wiring the policy threshold, suppressing intentional exceptions, and turning the output into a control attestation.

Scenario

• Repo. acme-co/infra — ~150 Terraform modules, ~80 Helm charts, three CloudFormation stacks.
• Constraint. A handful of legacy modules cannot satisfy the CIS benchmark today — we need to suppress them with a recorded justification, not just disable the scanner.
• Goal. A clean scan + an audit trail of every suppression.

1. Run the scan

If the infra is in the same repo as application code, connecting the repo once enables IaC scanning automatically — both Trivy IaC and Checkov fan out as part of the standard repo scan.

If infra lives in a dedicated repo:

curl -X POST -H "Authorization: Bearer $PENCHEFF_API_KEY" \
  "$PENCHEFF_API_BASE/repos/$REPO_ID/scan"

The scan opens at /repos/scans/{id} with a per-scanner card showing the Trivy IaC and Checkov counts.

2. Triage the noise

Both scanners default to flagging medium+. The Checkov rule pack is broad, so the unified findings view will surface a long list on the first run. Two paths to focus engineer attention:

• Filter at view time. The repo scan’s severity filter hides MEDIUM in one click.
• Suppress recurring noise. For policy hits that you’ve already accepted, suppress them with a justification (next step) — suppressed findings stay in the database but don’t appear on the report by default.

3. Suppress with a justification

A finding can be suppressed with one of:

• accepted_risk — known and accepted (recorded with reason
  • reviewer)
• wont_fix — acknowledged but not in remediation scope
• false_positive — confirmed noise
• duplicate — same root cause tracked elsewhere
• out_of_scope — outside agreed test scope

curl -X POST -H "Authorization: Bearer $PENCHEFF_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "reason": "accepted_risk",
    "notes": "Dev cluster only — does not handle production data. Reviewed by SRE 2026-04-12."
  }' \
  "$PENCHEFF_API_BASE/findings/$FINDING_ID/suppress"

Suppressions are logged with timestamp, user, and notes; they appear on the audit trail and survive re-scans.

4. Read the compliance rollup

/repos/scans/{id}/compliance — switch to NIST 800-53. IaC findings (category: iac or misconfiguration) light up:

• CM-6 — Configuration Settings
• CM-7 — Least Functionality
• SC-7 — Boundary Protection (when network-config flagged)

For PCI-DSS the same findings light up 2.2 / 6.2. For ISO 27001:2022 they hit A.8.8 / A.8.9.

5. Container hardening

When the repo also contains a Dockerfile, Trivy’s container image scanner fans out automatically. Findings carry the offending layer and the recommended fix line.

For images already in a registry (not in a connected repo), the MCP host exposes scan_container_image as a one-shot tool — pass the image reference (acme/api:1.42.0), it returns the same finding shape as the repo-scan path.

Deliverable

• A clean repo scan you can attach to the next infra PR.
• A signed-off suppression list for the legacy modules.
• A NIST 800-53 control rollup the auditor can ingest as evidence.

Next

• IaC feature reference.
• Tutorial: SBOM as evidence.
• Tutorial: Audit-ready bundle.