Cybersecurity
When to Use
- Security review of code, configs, or infrastructure
- Hardening a service, container, or deployment
- Investigating or remediating a vulnerability
- Implementing auth, encryption, or access control
Workflow
1. Threat Model First
Before writing code, identify:
- What assets need protection (data, endpoints, keys)
- Who are the threat actors (external, internal, supply chain)
- What's the attack surface (network, API, file system, deps)
2. Audit
Systematic check in priority order:
Secrets & Credentials:
- No hardcoded secrets (grep for API keys, passwords, tokens)
- Secrets in env vars or vault, never in code/config files
- Rotate exposed credentials immediately
Authentication & Authorization:
- Verify auth on every endpoint, not just frontend
- Check for broken access control (IDOR, privilege escalation)
- Validate JWT/session tokens server-side
Input Validation:
# WRONG: trusting user input
query = f"SELECT * FROM users WHERE id = {request.args['id']}"
# RIGHT: parameterized queries
cursor.execute("SELECT * FROM users WHERE id = %s", (request.args['id'],))
Dependency Security:
# Check for known vulnerabilities
npm audit --production
pip-audit
cargo audit
trivy image myapp:latest
Transport & Encryption:
- TLS 1.2+ for all connections
- HSTS headers on web services
- Encrypt sensitive data at rest (AES-256-GCM)
3. Harden
Container hardening:
# Non-root user
RUN adduser -D appuser
USER appuser
# Minimal base image
FROM gcr.io/distroless/static:nonroot
# No secrets in layers
# Use multi-stage builds, copy only artifacts
Network hardening:
- Default-deny network policies
- Restrict egress to required endpoints only
- No unnecessary open ports
Application hardening:
# Security headers (nginx example)
add_header X-Content-Type-Options nosniff;
add_header X-Frame-Options DENY;
add_header Content-Security-Policy "default-src 'self'";
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
4. Verify
- Run SAST/DAST scans (semgrep, bandit, gosec)
- Test auth bypass paths manually
- Verify secrets aren't in git history:
git log -p | grep -i 'password\|secret\|api.key'
- Check container as non-root:
docker run --user 1000 myapp whoami
Common Pitfalls
| Pitfall |
Fix |
| SQL injection via string concat |
Always use parameterized queries |
| Secrets in Docker layers |
Multi-stage build, copy only artifacts |
| JWT validated client-side only |
Always verify server-side with secret |
| CORS wildcard (*) in production |
Explicit allowed origins list |
| Running containers as root |
USER directive + read-only filesystem |
| Logging sensitive data |
Sanitize logs, never log tokens/passwords |
| Outdated dependencies with CVEs |
Automated audit in CI pipeline |
Output Expectations
- Provide specific fixes with code, not just recommendations
- Flag severity (critical/high/medium/low)
- Prioritize: secrets > auth > injection > config > deps
1---2name: cybersecurity-33description: Use for security audits, vulnerability remediation, hardening configs, and secure coding patterns. Not for compliance frameworks or policy writing.4---5
6# Cybersecurity
7
8## When to Use
9- Security review of code, configs, or infrastructure
10- Hardening a service, container, or deployment
11- Investigating or remediating a vulnerability
12- Implementing auth, encryption, or access control
13
14## Workflow
15
16### 1. Threat Model First
17Before writing code, identify:
18- What assets need protection (data, endpoints, keys)
19- Who are the threat actors (external, internal, supply chain)
20- What's the attack surface (network, API, file system, deps)
21
22### 2. Audit
23Systematic check in priority order:
24
25**Secrets & Credentials:**
26- No hardcoded secrets (grep for API keys, passwords, tokens)
27- Secrets in env vars or vault, never in code/config files
28- Rotate exposed credentials immediately
29
30**Authentication & Authorization:**
31- Verify auth on every endpoint, not just frontend
32- Check for broken access control (IDOR, privilege escalation)
33- Validate JWT/session tokens server-side
34
35**Input Validation:**
36```python
37# WRONG: trusting user input
38query = f"SELECT * FROM users WHERE id = {request.args['id']}"
39
40# RIGHT: parameterized queries
41cursor.execute("SELECT * FROM users WHERE id = %s", (request.args['id'],))
42```
43
44**Dependency Security:**
45```bash
46# Check for known vulnerabilities
47npm audit --production
48pip-audit
49cargo audit
50trivy image myapp:latest
51```
52
53**Transport & Encryption:**
54- TLS 1.2+ for all connections
55- HSTS headers on web services
56- Encrypt sensitive data at rest (AES-256-GCM)
57
58### 3. Harden
59
60**Container hardening:**
61```dockerfile
62# Non-root user
63RUN adduser -D appuser
64USER appuser
65
66# Minimal base image
67FROM gcr.io/distroless/static:nonroot
68
69# No secrets in layers
70# Use multi-stage builds, copy only artifacts
71```
72
73**Network hardening:**
74- Default-deny network policies
75- Restrict egress to required endpoints only
76- No unnecessary open ports
77
78**Application hardening:**
79```yaml
80# Security headers (nginx example)
81add_header X-Content-Type-Options nosniff;
82add_header X-Frame-Options DENY;
83add_header Content-Security-Policy "default-src 'self'";
84add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
85```
86
87### 4. Verify
88- Run SAST/DAST scans (semgrep, bandit, gosec)
89- Test auth bypass paths manually
90- Verify secrets aren't in git history: `git log -p | grep -i 'password\|secret\|api.key'`
91- Check container as non-root: `docker run --user 1000 myapp whoami`
92
93## Common Pitfalls
94| Pitfall | Fix |
95|---------|-----|
96| SQL injection via string concat | Always use parameterized queries |
97| Secrets in Docker layers | Multi-stage build, copy only artifacts |
98| JWT validated client-side only | Always verify server-side with secret |
99| CORS wildcard (*) in production | Explicit allowed origins list |
100| Running containers as root | USER directive + read-only filesystem |
101| Logging sensitive data | Sanitize logs, never log tokens/passwords |
102| Outdated dependencies with CVEs | Automated audit in CI pipeline |
103
104## Output Expectations
105- Provide specific fixes with code, not just recommendations
106- Flag severity (critical/high/medium/low)
107- Prioritize: secrets > auth > injection > config > deps
aibot88