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 is designed with 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 three credentials from Detectify:
| Credential | Purpose | Storage Recommendation |
|---|---|---|
| License Key | Activates the scanner | Kubernetes Secret (KMS encrypted) |
| Connector API Key | API authentication | Kubernetes Secret (KMS encrypted) |
| Registry Credentials | Pull container images | Kubernetes Secret (KMS encrypted) |
These credentials are provided by Detectify and are specific to your organization. See Secrets Management for secure handling practices.
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
Deployment
- Deploy in private subnets with no public IPs
- Use internal load balancer only (no public endpoint)
- Enable KMS encryption for Kubernetes secrets
- Restrict IAM permissions to minimum required
Credentials
- Store credentials using KMS encryption (guide)
- Never commit credentials to version control
- Use separate credentials per environment (prod/staging)
- If compromise is suspected, disable credentials in Detectify Platform and contact support
Network
- Limit scanner’s network access to only required applications
- Use security groups to control scanner-to-app communication
- Monitor outbound traffic for anomalies
- Keep scanner in separate namespace from production workloads
Operations
- Enable CloudWatch/monitoring for the scanner
- Set up alerts for scanner failures
- Regularly update scanner version for security patches
- Review scan results and remediate findings
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.
What if my applications contain sensitive data?
The scanner only sends vulnerability metadata to Detectify, not application data. Response bodies, database contents, and authentication tokens are analyzed locally and never transmitted.
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 metadata 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