Security Scanning

Proofarc integrates multiple security scanning tools through a distributed agent architecture. Scanners run in isolated containers and report results back to the platform.

Available Scanners

Scanner	Category	What it finds
Nmap	Network	Open ports, services, OS detection
Nikto	Web	Web server misconfigurations, default files
Nuclei	Vulnerability	CVEs, misconfigurations, exposures
ZAP	Web App	XSS, SQL injection, CSRF, security headers
SQLMap	Injection	SQL injection vulnerabilities
Trivy	Container	Container image vulnerabilities, misconfigs

How It Works

1. Select a target — any environment target (REST_SERVICE, WEB_APP, NETWORK)
2. Choose a scan template — pre-configured scanner profiles (62 templates available)
3. Execute — the scanner agent picks up the job, runs the tool, reports results
4. Findings — vulnerabilities are deduplicated, lifecycle-tracked, and scored

Finding Lifecycle

Every finding goes through a tracked lifecycle:

OPEN → TRIAGED → IN_PROGRESS → FIXED → VERIFIED
                                   ↑
                              REOPENED (if it comes back)

• Deduplication: Same vulnerability across scans = one finding, occurrence count incremented
• Version tracking: Which version introduced it, which version fixed it
• Reopening: If a fixed finding reappears, it's marked REOPENED with 1.2x score penalty
• Jira integration: Auto-creates tickets for CRITICAL/HIGH findings

Authenticated Scanning

Security scanners automatically use the same auth configured on your environment target. If your target has Bearer, OAuth2, Basic, or API Key auth, every scanner will include the auth header in its requests — no extra configuration needed.

How It Works

1. Configure auth on your environment target (same auth used for API scenarios)
2. Run any security scan against that target
3. The platform injects the auth config into scan parameters automatically
4. The scanner fetches a token (if needed) and applies it to every request

Supported Auth Per Scanner

Scanner	Auth Injection	CLI Flag
ZAP	Replacer rule — adds header to every request	-config replacer.full_list(0)...
Nikto	Custom header	-H "Authorization: Bearer ..."
Nuclei	Custom header	--header "Authorization: Bearer ..."
SQLMap	Custom header	--headers "Authorization: Bearer ..."
Nmap	N/A (network-level, no HTTP auth)	—

Auth Types

Type	Mode	What Happens
Bearer (Login)	AUTO	Scanner calls login endpoint, extracts token, applies to requests
OAuth2 Client	AUTO	Scanner calls token endpoint with client credentials
Static Bearer	STATIC	Token used directly
Basic Auth	STATIC	Username:password base64-encoded
API Key	STATIC	Key injected as custom header

Example: ZAP with Bearer Auth

# Target already has auth configured on the environment target.
# Just run the scan — auth is injected automatically.

# Create a scan group and execute
POST /api/scan-group
{
  "name": "ZAP Auth Scan",
  "templateIds": [22],
  "targetIds": [1],
  "parameters": {"scan_type": "full"}
}

POST /api/scan-group/{id}/execute

ZAP will:

1. Call your login endpoint to get a token
2. Inject the Authorization: Bearer <token> header via ZAP's replacer
3. Spider and scan authenticated pages that require login

Why This Matters

Without auth, scanners only see public pages and unauthenticated error responses. With auth:

• ZAP discovers more pages behind login walls
• Nikto checks authenticated admin panels
• Nuclei tests authenticated endpoints for CVEs
• SQLMap tests authenticated form inputs

Scan Groups

Group multiple scans for parallel or sequential execution:

# Create a scan group with multiple templates
POST /api/scan-group
{
  "name": "Full Security Audit",
  "templateIds": [1, 5, 22],
  "targetIds": [1]
}

# Execute the group — all scans run in parallel
POST /api/scan-group/{id}/execute