Security & Privacy
This page describes the security architecture of the Internal Scanning Agent, how data is handled, and compliance considerations.
Security Model
The Internal Scanning Agent uses a zero-trust, defense-in-depth approach:
┌─────────────────────────────────────────────────────────────────────────────────┐
│ SECURITY ARCHITECTURE │
├─────────────────────────────────────────────────────────────────────────────────┤
│ │
│ YOUR INFRASTRUCTURE │
│ ┌───────────────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ PRIVATE SUBNET (No public IPs) │ │
│ │ ┌───────────────────────────────────────────────────────────────┐ │ │
│ │ │ │ │ │
│ │ │ ┌─────────────────────┐ ┌─────────────────────┐ │ │ │
│ │ │ │ Internal Scanner │ │ Your Applications │ │ │ │
│ │ │ │ │──────►│ │ │ │ │
│ │ │ │ • No public IP │ │ • APIs │ │ │ │
│ │ │ │ • Internal LB only │ │ • Web apps │ │ │ │
│ │ │ │ • Encrypted at rest│ │ │ │ │ │
│ │ │ └──────────┬──────────┘ └─────────────────────┘ │ │ │
│ │ │ │ │ │ │
│ │ └─────────────┼─────────────────────────────────────────────────┘ │ │
│ │ │ │ │
│ │ OUTBOUND INTERNET (NAT Gateway or Internet Gateway) │ │
│ │ ┌─────────────▼─────────────┐ │ │
│ │ │ • No inbound allowed │ │ │
│ │ │ • TLS 1.3 required │ │ │
│ │ │ • Certificate validation │ │ │
│ │ └─────────────┬─────────────┘ │ │
│ │ │ │ │
│ └─────────────────┼─────────────────────────────────────────────────────┘ │
│ │ │
│ │ HTTPS 443 (Outbound only) │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────────────────┐ │
│ │ DETECTIFY PLATFORM │ │
│ │ │ │
│ │ • Scan scheduling & orchestration │ │
│ │ • Results dashboard │ │
│ │ • Vulnerability management │ │
│ │ • Data encrypted at rest │ │
│ └─────────────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────────┘Key Security Properties
No Inbound Access Required
| Property | Implementation |
|---|---|
| No public IPs | Scanner runs in private subnets with no public IP addresses |
| No inbound rules | No firewall or security group rules allowing inbound internet traffic |
| Internal load balancer | Scanner endpoint only accessible within your VPC |
| Outbound polling | Scanner initiates all communication with Detectify (pull model) |
Encryption
| Layer | Protection |
|---|---|
| In Transit | TLS 1.3 for all external communication |
| At Rest | KMS encryption for Kubernetes secrets (configurable) |
| Credentials | Stored as Kubernetes secrets, optionally encrypted with your KMS key |
Network Isolation
The scanner is deployed in private subnets and communicates only with:
- Your internal applications (for scanning)
- Detectify platform (outbound HTTPS only)
*.detectify.com(API, container registry, all Detectify services)
Data Flow
What Leaves Your Network
Only scan metadata and vulnerability findings are sent to Detectify:
┌────────────────────────────────────────────────────────────────────────────────┐
│ DATA CLASSIFICATION │
├────────────────────────────────────────────────────────────────────────────────┤
│ │
│ SENT TO DETECTIFY NEVER LEAVES YOUR NETWORK │
│ ───────────────── ──────────────────────── │
│ │
│ ✓ Vulnerability type ✗ Application source code │
│ ✓ Affected URL path ✗ Full HTTP request bodies │
│ ✓ Severity level ✗ Full HTTP response bodies │
│ ✓ CVE identifiers ✗ Authentication tokens/cookies │
│ ✓ Remediation guidance ✗ Database query results │
│ ✓ Scan progress status ✗ Internal file contents │
│ ✗ Environment variables │
│ ✗ Secrets or credentials │
│ ✗ PII or customer data │
│ │
└────────────────────────────────────────────────────────────────────────────────┘Example: What a Finding Contains
When the scanner detects a vulnerability, this is what gets sent:
{
"type": "sql-injection",
"severity": "high",
"url": "https://internal-app.company.com/api/users",
"parameter": "id",
"evidence": "Error message indicates SQL syntax",
"cve": "CWE-89",
"first_seen": "2024-01-15T10:30:00Z"
}Not sent: The actual SQL query, database contents, or response data.
Credential Security
The scanner requires credentials from Detectify (license key, connector API key, registry credentials). For the full list and where to find them, see Requirements. For secure handling, see Secrets Management.
Credential Lifecycle
- Credentials are generated by Detectify when Internal Scanning is enabled
- Credentials have a validity period managed by Detectify
- If credentials are compromised, disable them in the Detectify Platform and contact Detectify support
- Credentials should be stored encrypted (KMS) and never committed to version control
Compliance Considerations
Your Responsibilities
| Area | Responsibility |
|---|---|
| Infrastructure security | Secure your Kubernetes cluster, VPC, and IAM policies |
| Network segmentation | Control which applications the scanner can access |
| Credential management | Store credentials securely using KMS encryption |
| Access control | Limit who can deploy and configure the scanner |
| Audit logging | Enable CloudTrail/audit logs for your cloud account |
Detectify’s Responsibilities
| Area | Coverage |
|---|---|
| Platform security | Secure infrastructure with industry certifications |
| Data protection | Encrypted at rest, access controlled |
| Vulnerability data | Secure storage with retention policies |
| Availability | High availability platform |
For details on Detectify’s security certifications and compliance, see Detectify Security & Compliance .
Audit Trail
All scanner activity is logged:
| Log Type | Location | Contains |
|---|---|---|
| Scan execution | Your cluster (kubectl logs) | Scan progress, targets, errors |
| API calls | CloudTrail (AWS) | Terraform/kubectl actions |
| Results access | Detectify platform | Who viewed findings, when |
Security Best Practices
- Deploy in private subnets with no public IPs and internal load balancer only
- Store credentials using KMS encryption — see Secrets Management
- Limit scanner network access to only required applications
- Enable CloudWatch monitoring
- Regularly update scanner version for security patches
Frequently Asked Questions
Can Detectify access my internal applications?
No. Detectify cannot initiate connections to your network. All communication is outbound from your scanner to Detectify. The scanner runs entirely in your infrastructure.
Can I restrict which applications the scanner can access?
Yes. Use Kubernetes network policies or security groups to limit which applications the scanner can reach. The scanner only scans applications you explicitly configure as targets.
How do I know the scanner isn’t sending unauthorized data?
- All outbound traffic goes through your NAT Gateway or Internet Gateway (monitorable)
- The scanner only sends findings data to Detectify as documented
Is the scanner itself secure?
- Container images are signed and scanned for vulnerabilities
- The scanner runs with non-root privileges
- No persistent storage of application data
- Regular security updates released by Detectify
Next Steps
- Requirements - Infrastructure prerequisites
- Secrets Management - Secure credential handling
- Deploy on AWS - Get started
Last updated on