Methodology

Evidence-backed checks across app, code, release, and monitoring.

BoringSec focuses on app, code, config, repository, and launch-surface risks that small teams can actually fix. The scope is intentionally narrower than enterprise vulnerability management, and the findings are written for remediation.

What we check

Runtime web posture: headers, TLS, DNS, public exposure, cookies, CORS, platform fingerprinting, and reputation signals.
Deep app checks: injection, XSS, subdomains, WAF posture, exposed ports, GDPR/privacy signals, bundle secrets, Supabase, Firebase, client-side threats, and external engines.
Repository and launch checks: GitHub repository scanning, code-quality heuristics, leaked API artifacts, secrets, dependency risk, SAST, and filesystem misconfiguration scans.
Care monitoring probes: uptime, SSL expiry, DNS changes, blacklist/reputation, client-threat, defacement, and recurring deep scans.

Evidence policy

Findings need a concrete affected URL, header, configuration signal, bundle evidence, or scanner observation.
High and critical findings are expected to include proof or a defensible reason when proof is not safe to expose.
Reports separate confirmed findings from preview/sample copy, release-gate blockers, and scanner availability notes.
Every remediation item should be understandable by a founder and actionable by an AI coding tool.

Runtime scanner inventory

Public URL scanning publishes 20 base URL modules plus 3 verified-owner background engines. External tools are bounded, non-destructive, and represented as availability notes when the runtime or budget cannot verify them safely.

7 base modules

Fast web posture

These checks run early because they catch common launch mistakes quickly without touching unsafe paths.

HeadersTLS/SSLDNS + SPFExposureCookiesCORSPlatform

13 base modules

Extended base surface

Extended base modules expand from headers into app behavior, public artifacts, framework clues, reputation feeds, and privacy/security misconfigurations.

Technology fingerprintingInjectionXSSSubdomainsWAF posturePortsGDPR/privacyBundle secretsSupabaseFirebaseReputationClient threatsVirusTotal

3 engines

Verified-owner background engines

These engines run independently only for eligible verified-owner scans, never block the base report, and publish explicit queued, running, unavailable, or terminal states.

NucleiOWASP ZAPMedusa

Legal and auth evidence boundary

The scanner records only what each surface can establish. Conditional coverage and unavailable evidence remain visible and never become a passing control.

Privacy, consent, and data rights signals

implemented

Initial URL response plus bounded same-origin privacy-policy fetches. Consent controls, first-response cookies, trackers, controller/DPO language, legal basis, recipients, retention, deletion/export rights, complaints, transfers, and safeguards are recorded with matched evidence.

Limit: JavaScript-rendered controls and later browser interactions are not executed in this pass; missing evidence is partial or not observed, not proof of non-compliance.

Terms, WCAG basics, and public notices

implemented

Initial HTML plus a bounded same-origin fetch of an explicitly linked terms page. Terms availability, licensing/IP language, document language, page title, image alt attributes, main landmark, form-control names, button names, copyright notice, and licensing/attribution links are recorded independently.

Limit: This is not a full WCAG audit, legal opinion, intellectual-property clearance, or proof that a document is enforceable in every jurisdiction.

Public authentication signals

implemented

Public response headers, cookies, shipped JavaScript, login links, entry-page forms, and at most one bounded same-origin login-page fetch. Session-cookie flags, client-side token storage signals, exposed auth artifacts, CORS, login-surface applicability, and static anti-CSRF token signals are assessed when observable.

Limit: MFA, enumeration, IDOR, server-side CSRF enforcement, and JWT claim/lifetime checks remain not assessed by a public scan. A public scan does not log in, create accounts, submit state-changing forms, modify tokens, or replay object identifiers.

Authenticated application surface

conditional

Verified-owner domains with an explicitly configured, expiring credential profile. The credential is attached only inside the isolated ZAP deep-scan boundary and is scoped to the verified hostname/origin. The test path validates access and the form-login path establishes a bounded session; neither is a ZAP path allowlist, so ZAP may spider other same-host paths. The public report exposes authentication status, never credential names or values.

Limit: The current single-credential ZAP flow has no scenario DSL or second identity and does not support MFA, enumeration, IDOR/tenant-isolation, or transaction-authorization verification; those controls remain not assessed and require dedicated authorized testing or manual review. CSRF or JWT findings may surface opportunistically, but their absence is not a pass.

Repository auth and authorization patterns

conditional

User-authorized repository or archive scan. Selected OAuth linking, token storage, cookie configuration, JWT verification, middleware coverage, secret, dependency, and webhook patterns are checked against the submitted source.

Limit: Source patterns are evidence leads, not runtime proof. Business-object ownership and role policy still require dedicated authorized tests or manual review.

Formal legal or accessibility certification

not assessed

Outside automated product scope. BoringSec links each automated observation to its evidence and applicable reference.

Limit: The report is not legal advice, a penetration-test attestation, or certification of GDPR, CCPA, WCAG, SOC 2, ISO 27001, or licensing compliance.

Repository and release scanning

Runtime scans show what a browser or attacker can see from the outside. Repository and CI scanners cover code hygiene, leaked contracts, secrets, dependency exposure, SAST, and release-blocking artifacts before changes land on main.

GitHub repository scanner

Repository checks look for code and delivery hygiene problems that a public URL scan cannot see.

Repository metadata and file inventory
TypeScript strictness
Dependency hygiene
Test coverage presence
Dead-code signals

Release security gate

Release checks block high/critical findings before mainline release and keep artifacts redacted in CI output.

Swagger/OpenAPI/Postman/Insomnia/Redoc leak scan
Spectral OpenAPI rules
Gitleaks
TruffleHog verified secrets
Semgrep default, secrets, and Next.js/Stripe rules
npm audit
OSV Scanner
Trivy filesystem scan
CodeQL JavaScript/TypeScript
Guarded ZAP API scan
Public exposure monitor

Connected scan coverage

Public URL scans run from BoringSec SaaS. Internal, cloud, container, and Kubernetes scans run from customer-controlled CI or a customer-side runner with explicit scope. Unavailable or unconfigured scanners are not counted as clean, and detection readiness is not a SOC replacement.

Public web runtime scan

Available

Execution: BoringSec SaaS
Engines: headers, ssl, dns, exposure, cookies, cors, platform, technology, injection, xss, subdomains, waf, ports, gdpr, bundle secrets, supabase, firebase, reputation, client threats, nuclei, zap, medusa, virustotal

Repository release gate

Available

Execution: GitHub Actions, Bitbucket Pipelines
Engines: swagger leak scan, spectral, gitleaks, trufflehog, semgrep, npm audit, osv scanner, trivy, codeql, zap api scan, public exposure monitor

AWS cloud posture scan

Planned

Execution: Customer runner, Customer VPC
Engines: prowler

Internal network safe scan

Planned

Execution: Customer runner, Customer VPC
Engines: naabu, nmap

Container SBOM vulnerability scan

Planned

Execution: GitHub Actions, Bitbucket Pipelines, Customer runner
Engines: syft, grype, trivy

Kubernetes posture scan

Planned

Execution: Customer Kubernetes
Engines: kubescape, kube bench, trivy

Detection readiness assessment

Not a replacement

Execution: Customer runner, Customer VPC, Customer Kubernetes
Engines: modsecurity crs, coraza, wazuh, falco, osquery, sigma, suricata

Release gate rules

The release gate is deliberately fail-closed. A pull request should not be able to hide leaked API docs, downgrade blocker severity, or write scanner output outside the repository workspace.

Leaked API contracts are private by default. Allowlisting requires a path, sha256 fingerprint, owner, and reason.

Critical and high severities cannot be removed from the release gate by pull-request config.

Scanner artifacts must stay repository-local; absolute paths, traversal, and symlink escapes fail closed.

ZAP API scans are manual, staging-only, and require explicit host allowlists before a checked-in OpenAPI file can be scanned.

Public exposure monitoring uses GitHub code search when tokens are configured and explicitly marks Bitbucket broad public-code coverage as incomplete until provider search is implemented.

How to connect BoringSec

Teams usually start with a public URL scan, then add repository access and CI release checks once they want every mainline change guarded before release.

1. Start with a public URL scan

Run a scan against the production or staging URL you want reviewed. BoringSec validates redirects and keeps public URL checks bounded.

Enter the URL from the scan form or dashboard.
Review the first report for confirmed findings and scanner availability notes.
Add the domain to Care monitoring when you need recurring checks and alerts.

2. Connect repository scanning

Repository checks need read access to the code tree so BoringSec can inspect package metadata, TypeScript settings, CI files, and selected source files.

Connect GitHub with the minimum read-only repository scope needed for the scan.
Choose the repository and default branch that represents release code.
Keep private tokens server-side; do not paste repository tokens into examples, docs, or screenshots.

3. Install the CI release gate

For GitHub Actions or Bitbucket Pipelines, add the release-gate workflow before merging to main. The gate should fail pull requests on high and critical blockers.

Run dependency install, then the Swagger/API artifact scanner, then the release gate aggregator.
Upload redacted artifacts from artifacts/security/ for review.
Require security-owner review for changes to release-gate config and API-spec allowlists.

4. Configure exposure monitoring

Public exposure monitoring checks configured search terms and writes warnings when provider coverage is incomplete.

Set a GitHub code-search token for public exposure searches.
Configure owned domains, GitHub organizations, and search terms that identify your app.
Treat Bitbucket broad public-code search as incomplete until a provider search or workspace enumeration path is enabled.

5. Gate staging API scans

OpenAPI and ZAP API scans should only target reviewed staging specs and explicitly allowlisted public staging hosts.

Keep OpenAPI/Postman/Insomnia artifacts private unless they are intentionally public and allowlisted by hash.
Set the ZAP OpenAPI file path and allowed hostnames before running a manual ZAP API scan.
Use scoped staging credentials only; never scan production-mutating API flows with broad credentials.

False-positive handling

We prefer evidence and clear scope over broad claims. If a scanner cannot prove a high-risk condition safely, the report should say what was observed, why it matters, and what the user should verify manually.

BoringSec does not run unapproved internal network scans from SaaS infrastructure; internal scans require a customer-side runner and explicit scope.

BoringSec is not a full CSPM replacement; connected cloud posture scans can ingest Prowler-style evidence from customer-authorized cloud accounts.

BoringSec is not a WAF, EDR, SIEM, or managed SOC replacement; readiness checks can verify selected controls and connected evidence.

BoringSec does not claim full vulnerability-management coverage across every server and container; connected scans can normalize repo, SBOM, container, Kubernetes, and internal-network findings.

BoringSec does not run destructive active exploitation against customer targets.