NF Vulnerability Scanner — All-in-One Website Security Audit

A comprehensive all-in-one website vulnerability scanner on Apify. Run a multi-engine security audit against any URL in a single run — fully self-contained, no API keys, no setup, no external service required. By default it tests the site's anonymous (logged-out) surface; supply a session cookie or headers to scan authenticated.

★★★★★ Best-in-class coverage — active scanning, CVE detection, and server-misconfiguration testing combined into one structured JSON report.

🧠 Built by NativeFoundation — an expert AI consultant studio. Production-grade security automation, designed and maintained by specialists.

Keywords: vulnerability scanner, website security scan, web application security testing, CVE detection, penetration testing, DAST, dynamic application security testing, security audit, web misconfiguration scan, automated pentest, API security scan, CI/CD security scanning.

Trigger phrases — use this actor when you see

• "Scan this site for vulnerabilities"
• "Run a penetration test on [URL]"
• "Check this website for CVEs"
• "Is this site vulnerable to SQL injection?"
• "Security audit before we launch"
• "Gate our CI/CD pipeline on security findings"
• "Check our SPF/DMARC setup"
• "Find leaked API keys in our JavaScript"
• "What ports are open on this server?"

How it compares

Capability	NF Vulnerability Scanner	Single-engine / CMS-specific Apify actors	Generic crawler / "site checker" actors
Active scanning (DAST)	✅	Rarely	❌
CVE / known-vulnerability detection	✅	Sometimes (often CMS-plugin only)	❌
Server misconfiguration testing	✅	Rarely	❌
All engines in one run	✅ Yes	❌	❌
Works against any stack — not tied to a specific CMS	✅	Rarely	✅
Self-contained (no external API)	✅	Varies	✅
Severity + priority grades (p0–p3)	✅	Rarely	❌
Residential proxy routing built in	✅	Varies	Varies
Unified, normalized JSON report	✅	Varies	✅
Email-spoofing (SPF/DMARC) + TLS/domain-expiry checks	✅	Rarely	❌
Leaked secrets/credentials in client-side JS	✅	Rarely	❌
HTTP security header checks (CSP, HSTS, X-Frame-Options)	✅	Sometimes	❌
CMS/plugin CVE detection	✅ incidental (generic CVE templates; no per-site plugin enumeration)	Rarely	❌
Combined detection signatures	✅ ~22,000 (aggregate of template/signature sets)	Typically hundreds–low thousands (narrower scope)	Varies, rarely disclosed
Pricing	✅ $0.25 (Standard) / $0.50 (Deep) event fee + your own Apify usage	Often pay-per-event — cost scales with memory allocation and page/site count	Varies

See Why choose this scanner below for the named head-to-head breakdown.

What it does

Two scan modes, selected via the scanMode input: Standard ($0.25) runs 9 engines; Deep ($0.50) runs Standard's 9 plus 4 more-intrusive engines. Their results are merged into a single, normalized report either way.

Standard mode (9 engines, $0.25)

Four are active DAST/CVE/misconfiguration engines:

Engine	What it does
Active scan	Active crawling, spidering, fuzzing, and injection testing
CVE scan	Known CVEs, exposed panels, and misconfigurations — including CVEs in popular CMS platforms and their plugins/extensions (e.g. WordPress core and plugins), via an actively-maintained open-source template set
Server scan	Web server misconfigurations and exposed default files
Port scan	Scans the target host's top 1000 TCP ports for open, publicly-reachable services (and flags exposed databases/admin services). Speed is configurable via portScanTiming (polite/normal/aggressive)

One more sends active traffic dedicated to a specific class of issue:

Engine

What it does

Tech fingerprint

Deeper technology/version fingerprinting than CMS scan's four platforms — CDNs, frameworks, JS libraries. Detection-only: GET requests only, no fuzzing. Flags 4 real misconfigurations as actual findings (directory listing enabled, exposed PHP errors, debug-mode indicators, verbose HTTP error pages); everything else it detects (library/server/CMS versions) is reported as an info-level tech inventory, not a vulnerability — it identifies the version but doesn't check it against a CVE database itself

The remaining four are passive — they don't send any attack traffic to the target, so they're safe to run on anything and finish in seconds:

Engine	What it does
DNS posture	Email-spoofing protection (SPF, DMARC, DKIM, BIMI), TLS certificate expiry, domain registration expiry
JS secrets	Crawls client-side JavaScript (inline + external) for leaked credentials (API keys, tokens, private keys) and risky patterns (eval, innerHTML)
Security headers	Checks the response for missing/misconfigured HTTP security headers (CSP, HSTS, X-Frame-Options, X-Content-Type-Options), insecure cookie flags (Secure/HttpOnly/SameSite), and over-permissive CORS
CMS scan	Native fingerprinting for WordPress, Drupal, Joomla, and Magento — version disclosure, exposed installer/admin endpoints, and platform-specific misconfigurations (e.g. WordPress XML-RPC/REST API exposure, Drupal's install.php, Joomla's unrenamed htaccess.txt, Magento's /magento_version). Self-gated: only probes the platform actually detected, and returns zero findings on sites running none of the four

Deep mode adds (4 more engines, $0.50 total)

These carry real footprint/risk on the target — brute-forcing, injection testing, and reconnaissance reach beyond the target itself — which is why they're gated behind the higher tier rather than on by default:

Engine	What it does
Content discovery	Directory/file brute-forcing for exposed paths — .git, .env, credential files, backups, admin panels
Injection test	A dedicated, more thorough SQL injection detector (detection-only — no data extraction or exploitation)
OSINT recon	Passive reconnaissance — subdomains and email addresses associated with the domain, discovered via public sources (certificate transparency logs, passive DNS). Never contacts the target directly
Subdomain enum	Standard DNS enumeration plus a zone-transfer (AXFR) attempt against the domain's nameservers — flags a classic, high-value misconfiguration distinct from DNS posture's SPF/DMARC/DKIM/BIMI/TLS/expiry checks

Combined coverage: across all thirteen engines (Deep mode), this Actor draws on ~22,000 combined detection signatures — an aggregate of the underlying template/signature sets (active fuzzing/injection rules, CVE and misconfiguration templates, known-dangerous-file and outdated-version checks, DNS/JS-secret/HTTP-header/technology-fingerprint patterns, a curated content-discovery wordlist, and top-1000 port coverage). It's an order-of-magnitude figure for total coverage, not a literal count of checks fired against every target.

When to use / when not to use

Use it for:

• An authorized, single-target security audit of a website you own or have explicit permission to test.
• CI/CD security gating — set failOnGrade/failOnSeverity and emit SARIF for GitHub/GitLab code scanning.

Do not use it for:

• Unauthorized scanning of systems you don't own or lack written permission to test — several engines send real active traffic (crawling, fuzzing, injection, port-scanning, and, in Deep mode, directory brute-forcing) and running them without authorization may be illegal.
• The deeper specialist coverage that is explicitly out of scope: dedicated plugin/theme CVE enumeration (WPScan), full TLS protocol/cipher auditing (testssl.sh/sslyze — this Actor checks certificate expiry only), client-side JS-library CVE detection (Retire.js), and MTA-STS email-policy checks.

Why choose this scanner (comparison)

vs. other Apify Actors

Most other security-audit Actors on Apify Store are narrow: they check HTTP security headers, TLS config, or a single CMS (typically WordPress, via its public plugin-CVE feed) and stop there. Ours combines active DAST, CVE detection, and server-misconfig testing with passive DNS/email and JS-secrets checks — in one run, against any site, not just a specific CMS.

Named, head-to-head — the closest things actually on the Store today:

• Kali Security Tools Actor (syntellect_ai) is the closest direct competitor by raw tool breadth — it wraps 600+ Kali Linux tools (including WPScan, which we deliberately don't bundle) behind a generic mode/targets input. But its own published output schema shows the cost of that generality: each finding carries the raw underlying tool name (no de-branding), there's no unified severity and priority grading (just a severity field), and results are split across three separate artifacts — an executive summary, a technical report, and an unprocessed raw/ dump — instead of one deduplicated, scored report. Pricing is $0.01 per 1,000 results, so cost scales with how noisy the scan is, not with how many engines you ran. We trade their raw tool count for one curated, normalized report with p0–p3 priority out of the box.
• Website Security & Vulnerability Audit (smart-digital) goes deeper than us on CMS breadth (7 platforms vs. our 4) and does real WordPress plugin/theme CVE lookups via WPVulnerability.net, which we don't attempt. But it has no active DAST, dedicated injection testing, or server-misconfiguration engine of its own — it's a CMS/header/TLS checker, not a full-site scanner. Pricing is $0.01/GB-memory event on actor start + $0.02/page audited, so cost scales with site size; ours doesn't.
• Domain Security Posture Checker, Email Security Scanner, and Security Headers Checker each do one slice of what our dns-posture/security-headers engines cover natively — DNS/WHOIS posture, email-auth depth (they add MTA-STS, which we don't check — our dns-posture engine does cover SPF, DMARC, DKIM, and BIMI), and a broader 10-header audit (vs. our 4), respectively. Each is a separate actor with its own run and its own bill; ours bundles the equivalent coverage as 2 of our 13 engines in a single run. If you specifically need MTA-STS or a 10-header checklist, they go deeper solo — worth knowing, not worth hiding.

Bottom line on named competitors: nobody else on the Store combines active scanning + CVE detection + server-misconfig + DNS/email + JS-secrets + headers + CMS + port + content-discovery + injection testing in one run with one normalized, severity-and-priority-graded report. The tradeoff is real: Kali Security Tools Actor beats us on raw tool count, smart-digital beats us on CMS-plugin-CVE depth, and the single-purpose actors go deeper on their one slice. We beat all of them on breadth-in-one-run and on report quality.

See the capability comparison table above for the feature-by-feature breakdown.

vs. off-Apify tools

Rolling your own equivalent means separately installing, configuring, and parsing several specialized open-source tools — e.g. a DAST crawler, a CVE/template scanner, and a server-misconfig scanner — each with its own output format and no shared severity scale, then building your own merge/dedup/scoring layer on top. This Actor consolidates that core stack. Note it does not replace a few deeper specialist tools: dedicated plugin/theme CVE enumeration (WPScan), full TLS protocol/cipher auditing (testssl.sh/sslyze — this Actor checks certificate expiry only), or client-side JS-library CVE detection (Retire.js) are out of scope; see the docs' coverage matrix for the full "what's not covered" list.

Capability	NF Vulnerability Scanner	Self-hosted open-source scanners	SaaS scanners (Detectify, Intruder, Qualys, Acunetix)
Zero install / zero infra	✅	❌ (manage binaries, deps, Docker)	✅
Multiple engines combined	✅	❌ (run + parse each separately)	Usually one engine
No subscription / pay-per-run	✅	✅ (but you host it)	❌ (expensive licenses)
Unified normalized findings	✅	❌ (different output formats)	✅
Built-in proxy / IP rotation	✅	❌ (DIY)	Varies
API + scheduling out of the box	✅ (Apify)	❌	✅
Time to first scan	< 1 min	Hours	Minutes–days (onboarding)
Email spoofing + cert/domain expiry monitoring	✅ (built in)	❌ (separate tool)	Usually a separate product
Leaked-secrets scanning of client-side JS	✅ (built in)	❌ (separate tool)	Rarely included
HTTP security header checks (CSP, HSTS, X-Frame-Options)	✅ (built in)	❌ (separate tool)	Varies
CMS/plugin CVE detection	✅ incidental via CVE scan (no per-site plugin enumeration — not WPScan-grade)	Varies (needs a WP-specific tool, e.g. WPScan)	Varies
Pricing	$0.25 (Standard) / $0.50 (Deep) event fee + your own Apify usage	$0 license, but you pay for compute + the engineering time to integrate and maintain several tools	Subscription — commonly low-hundreds to low-thousands of dollars/month at entry tiers

Bottom line: you get comprehensive multi-engine coverage with the convenience of a managed SaaS — at pay-per-run pricing, with no setup.

FAQ

Why should I use this instead of running the scanners myself? Running an equivalent scan yourself means installing, configuring, and separately parsing at least six tools (ZAP, Nuclei, Nikto, nmap, gobuster, sqlmap), each with its own output format, then building your own merge/dedup/severity-scoring layer on top. This Actor runs all of them — plus seven more native/passive checks — in one call and returns a single normalized, deduplicated, severity-and-priority-graded JSON report. No installation, no API keys, no infrastructure to maintain.

What makes it different from other Apify security actors? Most others check one thing — a single CMS, HTTP headers, or TLS config — and stop there. This is the only actor on the Store combining active DAST, CVE/template detection, server-misconfiguration testing, port scanning, content discovery, dedicated SQL injection testing, CMS fingerprinting, DNS/email posture, leaked-secret scanning, tech fingerprinting, and OSINT recon into one run with one report. See Why choose this scanner above for the named head-to-head against specific competitors.

Is it safe and legal to use? Only against targets you own or have explicit permission to test — see "Authorization required" below. In Standard mode, 4 of the 9 engines are passive and never send attack traffic; in Deep mode, 2 of the 4 added engines are also passive/no-target-contact. The rest send real crawling/fuzzing/injection/port-scan/brute-force traffic and require your representation via permissionConfirmed: true.

How long does a scan take? A Standard-mode run typically finishes in a few minutes. A full Deep-mode (thirteen-engine) run typically finishes in a few minutes too, worst case around 10 minutes when active-scan uses its full budget. Use scanMode: "standard" for a faster, narrower scan.

Do I need any API keys or infrastructure of my own? No. Every scanner binary is bundled in the Actor's Docker image and runs as a subprocess — no external API dependency, and nothing to install or maintain on your side.

Can it scan pages behind a login? Yes — pass cookies and/or requestHeaders to reach the authenticated surface. These are sent only to the target's own origin, never to third-party hosts. active-scan, server-scan, and tech-fingerprint always run unauthenticated regardless.

What do I actually get for the $0.25 / $0.50? One flat event fee per completed scan — $0.25 for a Standard-mode run, $0.50 for a Deep-mode run — regardless of how many findings came back. You're only charged if at least one engine actually completed — a run where the target was unreachable and every engine failed isn't billed. Your own Apify account is billed separately for that run's compute/proxy usage.

Does this replace a professional penetration test? No — it's built for continuous, automated coverage (CI/CD gating, recurring audits), not a substitute for manual, human-led testing. It also doesn't cover some specialist areas: dedicated WordPress plugin/theme CVE enumeration (WPScan), full TLS protocol/cipher auditing, or client-side JS-library CVE detection — see When to use / when not to use above.

What happens if the target is down or an engine fails? Per-engine failures don't abort the run — a failed or timed-out engine is recorded in the report's status/engineOutput and flagged in meta.coverageNote, while the other engines' results still come back. If every engine fails, the run isn't charged.

Can I use it in a CI/CD pipeline? Yes — set outputFormat: "sarif" for a SARIF 2.1.0 record you can upload to GitHub/GitLab code scanning, and set failOnGrade/failOnSeverity to make the run exit non-zero once a scan crosses your threshold, so a pipeline step can block a deploy on it.

Can an AI agent or MCP tool call this directly? Yes — it's designed to be one-shot and agent-callable: give it a URL (and permissionConfirmed: true), get back a single structured JSON (or SARIF) report an agent can parse directly. It's discoverable through the Apify MCP server like any other Actor, with no extra setup.

Can I run this on a schedule to monitor a site over time? Yes — set up an Apify schedule to run this Actor on a recurring basis (e.g. weekly) against the same target, and compare each run's summary.riskScore/grade over time to catch new CVEs or misconfigurations as they appear.

Pricing

Two flat event fees, one per scan mode, plus your own Apify platform usage for that run. A completed Standard run charges $0.25; a completed Deep run charges $0.50. No per-engine charges, no per-finding charges on our side — the price only depends on which mode ran, not on how many findings come back. You're only charged the event fee if at least one engine actually completes; a run where the target is unreachable and every engine fails isn't billed. Separately, compute and proxy usage for the run is billed directly to your own Apify account — that portion does scale with scan mode, target size, and how long the scan takes to run.

Input

Field	Type	Required	Default	Description
url	string	Yes	—	Target URL to scan
permissionConfirmed	boolean	Yes	false	Must be true. Confirms you own the target or have explicit permission from its owner to scan it. The run fails fast if this is missing or false.
scanMode	string	No	"standard"	"standard" (9 engines, $0.25) or "deep" (13 engines — adds SQL injection, directory brute-forcing & subdomain recon, $0.50)
portScanTiming	string	No	"normal"	How fast port-scan probes the target: polite, normal, or aggressive. Ignored unless port-scan is selected. Polite trades speed for a lighter footprint on the target
proxyConfiguration	object	No	Apify Datacenter	Proxy for the HTTP-based engines (see Proxy — port-scan, osint-recon, subdomain-enum, and the native engines always connect directly)
requestHeaders	object	No	—	Extra HTTP headers (e.g. {"Authorization": "Bearer …"}) for authenticated scanning. Sent only to the target's origin, never to third-party hosts
cookies	string	No	—	A Cookie header value (e.g. session=…) for authenticated scanning
outputFormat	string	No	"json"	json, sarif (also writes an OUTPUT.sarif SARIF 2.1.0 record for code scanning), or both
failOnGrade	string	No	—	CI gate: exit non-zero if the grade is this letter or worse (B/C/D/F). Report is still written and charged
failOnSeverity	string	No	—	CI gate: exit non-zero if any finding is at this severity or higher (low/medium/high/critical)

Scope: by default every engine scans the target's anonymous (logged-out) surface. active-scan, server-scan, and tech-fingerprint always run unauthenticated; the CVE, content-discovery (Deep mode), injection-test (Deep mode), and native engines pick up requestHeaders/cookies when provided, so set those to reach a logged-in surface. osint-recon and subdomain-enum (both Deep mode) don't apply — they never contact the target's own origin, only public sources and DNS servers. A scan visits the single URL given (plus each engine's own probes) — it does not spider the whole site, so the grade reflects the pages actually reached. A Standard-mode (9-engine) run typically takes a few minutes; a Deep-mode (13-engine) run typically takes a few minutes too (worst case ~10 min when active-scan uses its full budget).

Proxy

The HTTP-based active engines (active scan, CVE scan, content discovery, injection test, tech fingerprint) route their traffic through a proxy. Configure it with the standard Apify proxy picker. It defaults to datacenter proxy, which works on every Apify plan out of the box. For targets that block datacenter IPs, select the Residential group — this requires Residential access on the account running the Actor, and if that access is missing the scan falls back to a direct connection (noted in the report's proxy block) rather than failing. Proxy usage is billed automatically to the account running the Actor.

The proxy does not cover every engine, so it is not a guarantee that the target never sees this Actor's real IP:

dns-posture, js-secrets, security-headers, and cms-scan always connect directly (DNS/TLS/RDAP lookups and JS/header/page fetches aren't proxied) since they don't send any traffic worth hiding from the target. port-scan also always connects directly — Nmap's proxy support only covers SOCKS4 on TCP-connect scans and is considered experimental upstream, so raw port scanning isn't routed through the configured proxy. server-scan also always connects directly — Nikto's HTTPS-through-proxy support was measured taking 40+ minutes to reach the same result a direct connection reaches in seconds, making it unusable at any reasonable timeout budget. osint-recon and subdomain-enum never contact the target at all — they query public OSINT sources and the domain's own nameservers, respectively — so a proxy selection doesn't apply to them either way.

Output

A single unified, deduplicated report, written both to the default key-value store under the record OUTPUT and as one item in the default dataset (so the run's Dataset tab, CSV/Excel export, and downstream-actor chaining all work). When outputFormat is sarif/both, a SARIF 2.1.0 rendering is also written to the OUTPUT.sarif key-value record for GitHub/GitLab code scanning.

{
  "target": "https://example.com",
  "engines": ["cve-scan", "server-scan", "active-scan"],
  "status": { "cve-scan": "completed", "server-scan": "completed", "active-scan": "completed" },
  "meta": {
    "reportVersion": "1.1.0",
    "startedAt": "2026-07-02T13:38:49.128Z",
    "finishedAt": "2026-07-02T13:39:41.902Z",
    "durationMs": 52774,
    "enginesRequested": 3,
    "enginesCompleted": 3,
    "enginesErrored": 0,
    "enginesTimedOut": 0
    // "coverageNote" appears when an engine errored/timed out, so a partial scan
    // isn't mistaken for a clean bill of health.
  },
  "summary": {
    "totalFindings": 12,
    "riskScore": 64,
    "grade": "D",
    "duplicatesMerged": 4,
    "bySeverity": { "high": 2, "medium": 5, "low": 5 },
    "byPriority": { "p1": 2, "p2": 5, "p3": 5 },
    "byEngine": { "cve-scan": 1, "server-scan": 8, "active-scan": 3 }
  },
  "findings": [
    {
      "id": "NF-0001",
      "engines": ["active-scan"],
      "severity": "high",
      "priority": "p1",
      "title": "SQL Injection",
      "description": "...",
      "location": "https://example.com/login",
      "occurrences": 1
    }
  ],
  "engineOutput": {
    "cve-scan": { "status": "completed", "raw": "..." },
    "server-scan": { "status": "completed", "raw": "..." },
    "active-scan": { "status": "error", "error": "...", "raw": "..." }
  }
}

Every finding has the same shape regardless of which engine produced it, and findings are sorted by priority (p0 → p4).

Engine output (debugging)

engineOutput carries each engine's unparsed output and, if it failed, the error that caused it — useful for diagnosing why an engine reported nothing or errored out. Unlike the rest of the report, this isn't de-branded: it's each scanner's own output verbatim, so it can name the underlying tool. The native engines (dns-posture, js-secrets, security-headers, cms-scan) have no separate raw form, since their findings above already are their complete output.

Risk score & grade

summary.riskScore is a single 0–100 headline number (higher = riskier), weighted by severity so critical issues dominate. It maps to a letter grade (A safest → F worst): A = 0, B < 25, C < 50, D < 75, F ≥ 75. Handy for dashboards, alerting thresholds, and at-a-glance summaries.

Deduplication

When more than one engine reports the same issue at the same location, the findings are merged into a single entry rather than duplicated. The merge is non-destructive — it keeps every engine that reported it (engines), the highest severity, the most detailed description, and the number of raw matches (occurrences). summary.duplicatesMerged records how many duplicates were collapsed.

Run metadata (meta)

meta records provenance so a report is auditable and reproducible: reportVersion, startedAt/finishedAt/durationMs, and how many engines were requested vs. completed/errored/timed out. If any engine didn't finish, meta.coverageNote spells out that the grade reflects partial coverage — so a scan that couldn't run isn't mistaken for a clean result. (De-branded like the rest of the report: engine counts only, never tool names/versions.)

Authenticated scanning

By default the scan sees only the anonymous, logged-out surface. Pass cookies (a session cookie) and/or requestHeaders (e.g. an Authorization header) to reach the authenticated surface — these are sent only to the target's own origin and never forwarded to third-party hosts a page or redirect points at. They're threaded into the CVE, content-discovery, injection-test, and native engines; active-scan, server-scan, and tech-fingerprint remain unauthenticated. osint-recon and subdomain-enum don't apply — they never contact the target's own origin at all.

CI/CD gating

Set outputFormat: "sarif" (or "both") to emit a SARIF 2.1.0 record (OUTPUT.sarif) you can upload to GitHub code scanning or GitLab SAST. Set failOnGrade and/or failOnSeverity to make the run exit non-zero when the scan crosses your threshold, so a pipeline step can block a deploy on it — the report is still written and the run still billed first.

---

⚠️ Authorization required — only scan targets you have permission to test

Only scan targets you own or have explicit permission to test. Standard mode runs 9 engines, 5 of which (active scan, CVE scan, server scan, port scan, tech fingerprint) send real crawling, fuzzing, injection, and port-scanning traffic to the target. Deep mode adds 4 more engines, 2 of which (content discovery, injection test) send directory brute-forcing and SQL injection traffic. Running any of these against a system without the owner's authorization may be illegal (e.g. under the US Computer Fraud and Abuse Act, the UK Computer Misuse Act, or similar laws elsewhere) and may violate the target's terms of service.

Every run requires the permissionConfirmed input to be set to true. Setting it is your representation that you have that authorization — you are solely responsible for ensuring you actually have it. NativeFoundation is not responsible for scans run without proper authorization; that responsibility rests entirely with the person or organization running the scan.

---

Licenses & attribution

This Actor packages the following third-party open-source security tooling, redistributed in accordance with each one's license:

Component	License
OWASP ZAP (active-scan)	Apache-2.0
Nuclei + nuclei-templates (cve-scan)	MIT
Nikto (server-scan)	GPL-2.0
Gobuster (content-discovery)	Apache-2.0
sqlmap (injection-test)	GPL-2.0-or-later
Nmap (port-scan)	Nmap Public Source License
WhatWeb (tech-fingerprint)	GPL-2.0
theHarvester (osint-recon)	GPL-2.0
dnsrecon (subdomain-enum)	GPL-2.0
secretlint (linked into js-secrets)	MIT

cms-scan, dns-posture, js-secrets, and security-headers are native engines with no bundled third-party scanner binary — js-secrets links the secretlint npm package directly rather than shelling out to a subprocess.

Full attribution details and license texts are in the NOTICE gist (also bundled inside the built Docker image at /NOTICE and /THIRD-PARTY-LICENSES).

port-scan uses the Nmap Security Scanner to perform its tasks, as required by the Nmap Public Source License's external-deployment notice clause.