Integrations

Connected Scans

BoringSec’s runtime scanners see your site from the outside — the way an attacker does. Connected Scans extend coverage to the places a SaaS scanner can’t and shouldn’t reach: your CI pipeline, your cloud account, your private network, your cluster. The engines run in your infrastructure; only signed result artifacts come back to us.

How it works

Request a manifest. A team OWNER or ADMIN requests a connected-scan manifest via the API or CLI. Manifests are HMAC-SHA256-signed, valid for 15 minutes, and scoped to your verified domains and targets only.
Run the engine where the data lives. The BoringSec CLI prints exact, hardened commands for each supported engine (for example nmap -sV --version-light -T2 scoped to the signed targets).
Upload the artifact. Results are validated against strict schemas. Malformed or out-of-scope artifacts are rejected — for example, Nmap XML that includes hosts outside the signed scope fails closed.
We normalize and score. Each finding becomes a normalized security finding with severity, confidence, and a manual-verification flag where applicable. Findings join your report alongside runtime results.

Privacy: raw artifact content is never persisted. We store a SHA-256 hash, byte length, and the normalized findings — nothing else.

Capabilities

Public web runtime

live

Runs in: BoringSec SaaS

all runtime scanners

Repository release gate

live

Runs in: GitHub Actions / Bitbucket

gitleaks, trufflehog, semgrep, spectral, npm-audit, osv-scanner, trivy, codeql, zap-api-scan, swagger-leak-scan, public-exposure-monitor

AWS cloud posture

planned

Runs in: your runner / VPC

prowler

Internal network safe scan

planned

Runs in: your runner / VPC

naabu, nmap (scoped to approved private CIDRs)

Container SBOM & vulnerabilities

planned

Runs in: CI / your runner

syft, grype, trivy

Kubernetes posture

planned

Runs in: your cluster

kubescape, kube-bench, trivy

Detection readiness

assessment-only

Runs in: your runner / VPC / cluster

modsecurity-crs, coraza, wazuh, falco, osquery, sigma, suricata

Accepted artifact types

sarifcyclonedx-jsonspdx-jsongrype-jsontrivy-jsonprowler-jsonnmap-xmlkubescape-jsonreadiness-json

Dedicated normalizers exist for each; unknown or invalid schemas fail closed.

The release gate

The repository release gate turns your CI into a shipping decision:

Blocks on: any critical or high finding, any verified leaked secret, any exposed OpenAPI/Swagger document.
Warns on: medium findings.
Emits SARIF into your CI artifacts and posts results as code annotations (Bitbucket Code Insights supported).
A public-exposure monitor additionally searches for leaked API schemas, Postman collections, and high-value secrets referencing your project.

Evidence policy

Connected findings follow the same rules as everything else: runtime and release-gate capabilities report confirmed-only findings; cloud, network and Kubernetes posture findings carry a confidence score; detection-readiness results are explicitly readiness-only — they assess whether your monitoring would catch an attack, and are never presented as vulnerabilities.

FAQ

Do you get credentials to my cloud or cluster?

No. Engines run under your credentials in your environment. We only receive the result artifact, signed against a manifest you requested.

Can a leaked manifest be abused?

Manifests expire in 15 minutes, are bound to your verified targets, and artifacts that reference out-of-scope targets are rejected.

Why is Nmap “safe scan” only?

The CLI pins conservative flags (version-light detection, slow timing, no scripts) and the normalizer enforces target scope. The goal is inventory and exposure verification, not intrusion.