Container security challenges:

• Image Vulnerabilities: Base images may contain CVEs
• Runtime Security: Detecting malicious behavior during execution
• Configuration Issues: Insecure configs (root user, excessive privileges)
• Network Security: Container communication and external access
• Secrets Management: Handling API keys and credentials
• Supply Chain Security: Image integrity from build to deployment
• Compliance: Meeting regulations in dynamic environments

Traditional security approaches are less effective, requiring specialized tools like Falco and Trivy.

2. Explain the difference between image scanning and runtime security monitoring.

Difficulty: Beginner
Answer:
Image Scanning (Static Analysis):

• Performed on container images before or after deployment
• Identifies known vulnerabilities (CVEs) in OS packages and application dependencies
• Checks for misconfigurations and policy violations
• Example tools: Trivy, Clair, Snyk
• Provides security insights at build time
  Runtime Security Monitoring (Dynamic Analysis):
• Monitors containers during execution
• Detects anomalous behavior, policy violations, and security incidents
• Tracks system calls, network activity, and file access
• Example tools: Falco, Sysdig Secure
• Provides real-time threat detection
  Both approaches are complementary and essential for comprehensive container security.

3. What is Falco and what problem does it solve?

Difficulty: Beginner
Answer:
Falco is an open-source runtime security tool for detecting threats in containerized applications.

Key capabilities:

• Real-time threat detection via system call monitoring
• Rule-based detection with custom policies
• Kubernetes integration
• Multi-format alerting (syslog, HTTP, gRPC)
• Low overhead monitoring

Problems solved:

• Privilege escalation detection
• Unauthorized file access
• Suspicious network connections
• Container breakout attempts
• Compliance violations

4. What are the different output formats available in Falco?

Difficulty: Beginner
Answer:
Falco supports multiple output formats and channels:
Output Formats:

• Text: Human-readable format (default)
• JSON: Structured format for log aggregation tools
  Output Channels:
  1. Standard Output:

stdout_output:
  enabled: true

2. File Output:

file_output:
  enabled: true
  keep_alive: false
  filename: /var/log/falco.log

3. Syslog:

syslog_output:
  enabled: true
  facility: local0
  priority: info

4. HTTP Webhook:

http_output:
  enabled: true
  url: "https://webhook.site/unique-token"
  user_agent: "falco"

5. gRPC:

grpc:
  enabled: true
  bind_address: "0.0.0.0:5060"
  threadiness: 8

Example JSON Output:

{
  "output": "File below a known binary directory opened for writing",
  "priority": "Error",
  "rule": "Write below binary dir",
  "time": "2024-01-15T10:30:45.123456789Z",
  "output_fields": {
    "user.name": "root",
    "proc.cmdline": "touch /bin/malware",
    "fd.name": "/bin/malware"
  }
}

5. What is Trivy and what types of vulnerabilities can it detect?

Difficulty: Beginner
Answer:
Trivy is a comprehensive vulnerability scanner for containers and other artifacts. It's designed to be simple, fast, and reliable for DevSecOps integration.
Types of Vulnerabilities Detected:
1. OS Package Vulnerabilities:

• CVEs in Linux distribution packages (Alpine, Ubuntu, CentOS, etc.)
• Package-specific vulnerability databases
  2. Application Dependencies:
• Language-specific packages (npm, pip, gem, etc.)
• Known vulnerabilities in application libraries
  3. Infrastructure as Code (IaC):
• Terraform misconfigurations
• Kubernetes YAML security issues
• CloudFormation template problems
  4. Container Image Issues:
• Base image vulnerabilities
• Layer-by-layer analysis
• Distroless image support
  5. File System Scanning:
• Local directories and archives
• Git repositories
• SBOM (Software Bill of Materials) generation
  Key Features:
• Fast scanning with cached vulnerability databases
• Multiple output formats (JSON, table, SARIF)
• CI/CD integration support
• Offline scanning capabilities
• Policy-based scanning with custom rules

6. How do you scan a container image with Trivy? Provide examples.

Difficulty: Beginner
Answer:
Basic Container Image Scanning:

# Scan a Docker image
trivy image nginx:latest
# Scan with specific severity levels
trivy image --severity HIGH,CRITICAL ubuntu:20.04
# Output in JSON format
trivy image --format json nginx:latest > scan-results.json
# Scan and exit with error code if vulnerabilities found
trivy image --exit-code 1 --severity CRITICAL myapp:latest

# Scan specific vulnerability types
trivy image --vuln-type os,library nginx:latest

# Skip database update (for offline environments)
trivy image --skip-update nginx:latest

# Scan with custom policy
trivy image --policy ./policy.rego nginx:latest

# Generate SBOM
trivy image --format spdx-json nginx:latest > sbom.json

Kubernetes Integration:

# Scan all images in a namespace
kubectl get pods -o jsonpath='{.items[*].spec.containers[*].image}' | \
  xargs -n1 trivy image

# Scan using kubectl with Trivy operator
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/trivy-operator/main/deploy/static/trivy-operator.yaml

Output Example:
```
nginx:latest (alpine 3.17.3)

Total: 5 (UNKNOWN: 0, LOW: 0, MEDIUM: 1, HIGH: 3, CRITICAL: 1)

┌─────────────┬──────────────┬──────────┬─────────────────┬───────────────┬───────────────────────────────────────┐
│ Library │ Vulnerability│ Severity │ Installed Ver. │ Fixed Version │ Title │
├─────────────┼──────────────┼──────────┼─────────────────┼───────────────┼───────────────────────────────────────┤
│ busybox │ CVE-2023-42363│ CRITICAL │ 1.35.0-r17 │ 1.35.0-r18 │ busybox: use-after-free in awk │
└─────────────┴──────────────┴──────────┴─────────────────┴───────────────┴───────────────────────────────────────┘

### 7. How does Falco detect security events? Explain its architecture.

**Difficulty:** Intermediate
**Answer:**  
Falco's architecture consists of several key components:
**1. Data Sources:**
- **Kernel Module/eBPF**: Captures system calls at the kernel level
- **K8s Audit Logs**: Monitors Kubernetes API server events
- **Plugin Framework**: Extensible data source integration
**2. Rules Engine:**
- Processes events against predefined and custom rules
- Uses a domain-specific language for rule definitions
- Supports conditions, macros, and lists for flexible rule creation
**3. Alerting System:**
- Multiple output channels (stdout, syslog, HTTP webhooks, gRPC)
- Structured alert format with metadata
- Rate limiting and alert prioritization
**Detection Flow:**

System Calls → Kernel Module/eBPF → Falco Engine → Rules Evaluation → Alerts

Falco operates in userspace but receives kernel-level events, providing deep visibility with minimal performance impact.

### 8. What are Falco rules? Provide an example of a basic rule.

**Difficulty:** Intermediate
**Answer:**  
Falco rules define the conditions that trigger security alerts. They are written in YAML format and consist of several components:
**Rule Structure:**
- **rule**: Rule name
- **desc**: Description of what the rule detects
- **condition**: Boolean expression defining when to trigger
- **output**: Alert message format
- **priority**: Severity level (Emergency, Alert, Critical, Error, Warning, Notice, Informational, Debug)
**Example Rule:**
```yaml
- rule: Write below binary dir
  desc: An attempt to write to any file below a set of binary directories
  condition: >
    bin_dir and evt.dir = < and open_write
    and not package_mgmt_procs
    and not exe_running_docker_save
    and not python_running_get_pip
    and not python_running_ms_oms
  output: >
    File below a known binary directory opened for writing
    (user=%user.name command=%proc.cmdline file=%fd.name parent=%proc.pname pcmdline=%proc.pcmdline gparent=%proc.aname[2])
  priority: ERROR
  tags: [filesystem, mitre_persistence]

This rule detects attempts to write files in binary directories, which could indicate malware installation or system tampering.

9. How do you install and configure Falco in a Kubernetes cluster?

Difficulty: Intermediate
Answer:
Installation Methods:
1. Using Helm (Recommended):

# Add Falco Helm repository
helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update
# Install Falco with DaemonSet
helm install falco falcosecurity/falco \
  --set falco.grpc.enabled=true \
  --set falco.grpcOutput.enabled=true

2. Using kubectl with manifests:

kubectl apply -f https://raw.githubusercontent.com/falcosecurity/deploy-falco/main/kubernetes/falco-daemonset-configmap.yaml

Key Configuration Options:

• Driver Type: Choose between kernel module, eBPF, or modern eBPF probe
• Output Channels: Configure syslog, HTTP endpoints, or gRPC
• Rule Files: Custom rules and rule overrides
• Resource Limits: CPU and memory constraints for DaemonSet pods
  Example ConfigMap customization:

apiVersion: v1
kind: ConfigMap
metadata:
  name: falco-config
data:
  falco.yaml: |
    json_output: true
    json_include_output_property: true
    http_output:
      enabled: true
      url: "http://webhook-service:8080/falco-alerts"

10. What are Falco macros and lists? How do they improve rule management?

Difficulty: Intermediate
Answer:
Macros and Lists are Falco constructs that improve rule reusability and maintainability:
Lists - Named collections of items (strings, regexes):

- list: shell_binaries
  items: [bash, csh, ksh, sh, tcsh, zsh, dash]
- list: sensitive_files
  items: [/etc/passwd, /etc/shadow, /etc/sudoers]

Macros - Reusable condition fragments:

- macro: shell_procs
  condition: proc.name in (shell_binaries)
- macro: sensitive_file_access
  condition: fd.name in (sensitive_files)

Usage in Rules:

- rule: Shell spawned by untrusted binary
  desc: Detect shell spawned by non-standard process
  condition: >
    spawned_process and shell_procs and
    not proc.pname in (trusted_binaries)
  output: "Shell spawned by untrusted binary (user=%user.name shell=%proc.name parent=%proc.pname)"
  priority: WARNING

Benefits:

• Reusability: Same macro/list used across multiple rules
• Maintainability: Update once, affects all dependent rules
• Readability: Complex conditions become more understandable
• Consistency: Standardized definitions across rule sets

11. How can you customize Falco rules for your specific environment?

Difficulty: Intermediate
Answer:
Rule Customization Approaches:
1. Rule Overrides:

# Disable a default rule
- rule: Write below binary dir
  enabled: false
# Modify rule condition
- rule: Write below binary dir
  condition: >
    bin_dir and evt.dir = < and open_write
    and not package_mgmt_procs
    and not my_custom_exception
  append: true

2. Custom Lists and Macros:

# Add environment-specific exceptions
- list: allowed_binary_writers
  items: [my-app, deployment-tool]
- macro: my_custom_exception
  condition: proc.name in (allowed_binary_writers)

3. Environment-Specific Rules:

- rule: Sensitive Database Access
  desc: Detect access to production database files
  condition: >
    open_read and fd.name startswith "/var/lib/postgresql"
    and not proc.name in (postgres, pg_dump)
  output: "Unauthorized database file access (user=%user.name file=%fd.name)"
  priority: CRITICAL
  tags: [database, compliance]

4. Configuration Management:

• Use separate rule files for different environments
• Implement GitOps workflow for rule management
• Version control rule changes
• Test rules in staging before production deployment

12. What is the difference between Trivy's image, fs, and repo scan modes?

Difficulty: Intermediate
Answer:
1. Image Mode (trivy image):

• Scans container images from registries or local Docker daemon
• Analyzes layers for OS packages and application dependencies
• Supports various image formats (Docker, OCI, etc.)

trivy image python:3.9-alpine
trivy image --input image.tar  # Scan exported image

2. Filesystem Mode (trivy fs):

• Scans local directories and file systems
• Useful for CI/CD pipelines and development environments
• Can scan project directories before containerization

trivy fs /path/to/project
trivy fs --security-checks vuln,secret .  # Include secret scanning
trivy fs --skip-dirs node_modules ./app   # Exclude directories

3. Repository Mode (trivy repo):

• Scans remote Git repositories
• Analyzes Infrastructure as Code files
• Detects secrets and misconfigurations

trivy repo https://github.com/user/repo
trivy repo --branch main https://github.com/user/repo
trivy repo --include-dev-deps .  # Include development dependencies

Additional Modes:
4. SBOM Mode (trivy sbom):

trivy sbom nginx:latest  # Generate Software Bill of Materials

5. Kubernetes Mode (trivy k8s):

trivy k8s cluster  # Scan entire cluster
trivy k8s deployment/myapp  # Scan specific workload

Each mode is optimized for different use cases in the software development lifecycle.

13. How do you integrate Trivy into CI/CD pipelines?

Difficulty: Intermediate
Answer:
GitHub Actions Integration:

name: Container Security Scan
on: [push, pull_request]
jobs:
  security-scan:
    runs-on: ubuntu-latest
    steps:
    - name: Checkout code
      uses: actions/checkout@v3
    - name: Build Docker image
      run: docker build -t myapp:${{ github.sha }} .
    - name: Run Trivy vulnerability scanner
      uses: aquasecurity/trivy-action@master
      with:
        image-ref: 'myapp:${{ github.sha }}'
        format: 'sarif'
        output: 'trivy-results.sarif'
        exit-code: '1'
        severity: 'CRITICAL,HIGH'
    - name: Upload Trivy scan results
      uses: github/codeql-action/upload-sarif@v2
      with:
        sarif_file: 'trivy-results.sarif'

GitLab CI Integration:

stages:
  - build
  - security
container_scanning:
  stage: security
  image: aquasec/trivy:latest
  script:
    - trivy image --exit-code 1 --severity CRITICAL $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  artifacts:
    reports:
      container_scanning: gl-container-scanning-report.json
  only:
    - main
    - merge_requests

Jenkins Pipeline:

pipeline {
    agent any
    stages {
        stage('Security Scan') {
            steps {
                script {
                    sh 'docker pull aquasec/trivy:latest'
                    sh '''
                        docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
                        -v $PWD:/workspace aquasec/trivy:latest \
                        image --exit-code 1 --severity HIGH,CRITICAL myapp:latest
                    '''
                }
            }
        }
    }
}

Best Practices:

• Set appropriate exit codes for pipeline failures
• Cache vulnerability databases to improve performance
• Use policy-based scanning for consistent enforcement
• Generate reports in multiple formats for different stakeholders

14. How do you configure Trivy to ignore specific vulnerabilities or files?

Difficulty: Intermediate
Answer:
1. .trivyignore File:
Create a .trivyignore file to exclude specific CVEs:

# Ignore specific CVEs
CVE-2023-12345
CVE-2023-67890
# Ignore by package name
pkg:npm/lodash@*
# Ignore by file path
**/test/**
**/node_modules/**

2. Configuration File (trivy.yaml):

# trivy.yaml
scan:
  skip-dirs:
    - "node_modules"
    - "vendor"
  skip-files:
    - "**/*.test.js"
    - "**/Dockerfile"
vulnerability:
  ignore-unfixed: true
  ignore-policy: .trivyignore
severity:
  - HIGH
  - CRITICAL
format: json
output: scan-results.json

3. Command Line Options:

# Ignore unfixed vulnerabilities
trivy image --ignore-unfixed nginx:latest
# Skip specific directories
trivy fs --skip-dirs node_modules,vendor .
# Use custom ignore file
trivy image --ignorefile custom-ignore.txt myapp:latest
# Ignore specific vulnerability types
trivy image --vuln-type library nginx:latest

4. Policy-Based Ignores (OPA Rego):

# policy.rego
package trivy
ignore[msg] {
    input.vulnerabilities[_].vulnerability_id == "CVE-2023-12345"
    msg := "Ignore CVE-2023-12345 - Risk accepted"
}
ignore[msg] {
    input.vulnerabilities[_].pkg_name == "openssl"
    input.vulnerabilities[_].severity == "LOW"
    msg := "Ignore low severity OpenSSL vulnerabilities"
}

5. Environment-Specific Ignores:

# Different ignore files for different environments
trivy image --ignorefile .trivyignore.prod myapp:latest  # Production
trivy image --ignorefile .trivyignore.dev myapp:latest   # Development

15. What are Trivy's different security check types and when would you use each?

Difficulty: Intermediate
Answer:
Available Security Check Types:
1. Vulnerability Scanning (vuln):

• Purpose: Detect known CVEs in packages and libraries
• Use Case: Regular security assessment of dependencies

trivy image --security-checks vuln nginx:latest

2. Secret Detection (secret):

• Purpose: Find hardcoded secrets, API keys, passwords
• Use Case: Prevent credential leaks in repositories and images

trivy fs --security-checks secret .
trivy repo --security-checks secret https://github.com/user/repo

3. Misconfiguration Detection (config):

• Purpose: Identify security misconfigurations in IaC files
• Use Case: Kubernetes YAML, Terraform, CloudFormation validation

trivy fs --security-checks config ./kubernetes/
trivy repo --security-checks config https://github.com/user/infrastructure

4. License Scanning (license):

• Purpose: Detect package licenses and compliance issues
• Use Case: Ensure license compliance in commercial applications

trivy image --security-checks license myapp:latest

Combined Scanning:

# Multiple check types
trivy fs --security-checks vuln,secret,config .
# All available checks
trivy image --security-checks vuln,secret,config,license myapp:latest
# Default behavior (vuln only)
trivy image myapp:latest

Use Case Examples:
Development Phase:

# Pre-commit scanning
trivy fs --security-checks secret,config .

CI/CD Pipeline:

# Comprehensive scanning
trivy image --security-checks vuln,secret,config myapp:$BUILD_ID

Production Monitoring:

# Focus on vulnerabilities and misconfigurations
trivy k8s --security-checks vuln,config cluster

16. How do you troubleshoot Falco performance issues?

Difficulty: Expert
Answer:
Common Performance Issues and Solutions:
1. High CPU Usage:

# Check Falco metrics
curl http://localhost:8765/metrics
# Monitor rule efficiency
falco --stats-interval=30

Solutions:

• Tune rule conditions to be more specific
• Disable unnecessary rules
• Adjust sampling rates for high-frequency events
  2. Memory Consumption:

# Optimize buffer sizes
syscall_event_drops:
  max_burst: 1000
  simulate_drops: false

3. Event Drops:

# Monitor for dropped events
falco --stats-interval=10 | grep "Events processed"

Optimization Strategies:

• Rule Tuning: Use specific conditions to reduce false positives
• Filtering: Implement early filtering for noisy processes
• Resource Limits: Set appropriate CPU/memory limits in Kubernetes
• Driver Selection: Choose optimal driver (eBPF vs kernel module)
  Performance Monitoring:

# Enable metrics endpoint
webserver:
  enabled: true
  listen_port: 8765
  k8s_healthz_endpoint: /healthz

Troubleshooting Commands:

# Check Falco logs
kubectl logs -f daemonset/falco -n falco
# Monitor system resources
kubectl top pods -n falco
# Validate rules syntax
falco --validate /etc/falco/falco_rules.yaml

17. How do you use Trivy with Kubernetes and what is the Trivy Operator?

Difficulty: Expert
Answer:
Trivy Kubernetes Integration:
1. Direct Kubernetes Scanning:

# Scan entire cluster
trivy k8s cluster
# Scan specific namespace
trivy k8s ns/production
# Scan specific workloads
trivy k8s deployment/myapp
trivy k8s pod/mypod-abc123
# Include node scanning
trivy k8s cluster --include-kinds node

2. Trivy Operator:
The Trivy Operator is a Kubernetes controller that continuously monitors cluster security:
Installation:

# Install Trivy Operator
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/trivy-operator/main/deploy/static/trivy-operator.yaml
# Verify installation
kubectl get pods -n trivy-system

Key Features:

• Continuous Scanning: Automatically scans new workloads
• CRD-Based Results: Stores scan results as Kubernetes resources
• Multi-Scanner Support: Integrates with various security tools
• Compliance Reports: Generates compliance reports for regulations
  Custom Resource Definitions:

# VulnerabilityReport CRD example
apiVersion: aquasecurity.github.io/v1alpha1
kind: VulnerabilityReport
metadata:
  name: nginx-deployment-nginx
spec:
  artifact:
    repository: nginx
    tag: "latest"
  summary:
    criticalCount: 1
    highCount: 3

3. Configuration Example:

# ConfigMap for Trivy Operator
apiVersion: v1
kind: ConfigMap
metadata:
  name: trivy-operator
  namespace: trivy-system
data:
  trivy.severity: "CRITICAL,HIGH"
  trivy.ignoreUnfixed: "true"
  trivy.resources.requests.cpu: "100m"
  trivy.resources.requests.memory: "100M"

4. Querying Results:

# Get vulnerability reports
kubectl get vulnerabilityreports

# Get configuration audit reports
kubectl get configauditreports

# Describe specific report
kubectl describe vulnerabilityreport nginx-deployment-nginx

5. Integration with Monitoring:

# Prometheus monitoring
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: trivy-operator
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: trivy-operator
  endpoints:
  - port: metrics

18. How do you integrate Falco and Trivy together for comprehensive container security?

Difficulty: Expert
Answer:
Comprehensive Security Strategy:
1. Pipeline Integration:

# .github/workflows/security.yml
name: Container Security Pipeline
on: [push, pull_request]
jobs:
  security-scan:
    runs-on: ubuntu-latest
    steps:
    - name: Checkout
      uses: actions/checkout@v3
    # Build phase security
    - name: Trivy FS Scan
      run: |
        trivy fs --security-checks vuln,secret,config .
    - name: Build Image
      run: docker build -t myapp:${{ github.sha }} .
    # Image security scanning
    - name: Trivy Image Scan
      run: |
        trivy image --exit-code 1 --severity CRITICAL myapp:${{ github.sha }}
    # Deploy with runtime security
    - name: Deploy with Falco
      run: |
        helm upgrade --install myapp ./charts/myapp \
          --set image.tag=${{ github.sha }} \
          --set falco.enabled=true

2. Kubernetes Deployment with Both Tools:

# security-monitoring.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: security-monitoring
# Trivy Operator
apiVersion: apps/v1
kind: Deployment
metadata:
  name: trivy-operator
  namespace: security-monitoring
spec:
  template:
    spec:
      containers:
      - name: trivy-operator
        image: aquasec/trivy-operator:latest
        env:
        - name: OPERATOR_NAMESPACE
          value: security-monitoring
# Falco DaemonSet
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: falco
  namespace: security-monitoring
spec:
  template:
    spec:
      containers:
      - name: falco
        image: falcosecurity/falco:latest
        volumeMounts:
        - name: dev
          mountPath: /host/dev
        - name: proc
          mountPath: /host/proc

3. Alert Correlation and Response:

# Elasticsearch/Logstash configuration for correlation
# logstash.conf
input {
  http {
    port => 8080
    codec => json
  }
}
filter {
  if [tool] == "falco" {
    mutate { add_tag => "runtime-security" }
  }
  if [tool] == "trivy" {
    mutate { add_tag => "vulnerability-scan" }
  }
  # Correlate alerts by container/pod
  if [kubernetes][pod_name] {
    aggregate {
      task_id => "%{[kubernetes][pod_name]}"
      code => "
        map['alerts'] ||= []
        map['alerts'] << event.to_hash
      "
      push_map_as_event_on_timeout => true
      timeout => 300
    }
  }
}

4. Policy Integration:

# security-policy.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: security-policy
data:
  trivy-policy.rego: |
    package trivy
    fail[msg] {
      input.vulnerabilities[_].severity == "CRITICAL"
      msg := "Critical vulnerabilities not allowed"
    }
  falco-rules.yaml: |
    - rule: Trivy High Vulnerability Alert
      desc: Correlate with Trivy scan results
      condition: >
        spawned_process and proc.name in (known_vulnerable_binaries)
      output: "Process with known vulnerabilities started (proc=%proc.name)"
      priority: WARNING

Benefits of Integration:

• Shift-Left Security: Early detection with Trivy
• Runtime Protection: Continuous monitoring with Falco
• Compliance: Comprehensive audit trail
• Incident Response: Correlated alerts for faster response

19. What are the best practices for implementing container security in production?

Difficulty: Expert
Answer:
Comprehensive Production Security Strategy:
1. Multi-Layer Security Approach:
Build Time Security:

# Dockerfile best practices
FROM gcr.io/distroless/java:11
COPY --from=builder /app/target/*.jar app.jar
USER 1001:1001
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]

Pipeline Security:

# security-pipeline.yml
stages:
  - sast:
      script: trivy fs --security-checks vuln,secret .
  - image-scan:
      script: trivy image --exit-code 1 --severity CRITICAL $IMAGE
  - deploy:
      script: |
        kubectl apply -f deployment.yaml
        kubectl annotate deployment/myapp security.scan.date=$(date)

2. Runtime Security Configuration:

# production-security.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: falco-config
data:
  falco.yaml: |
    rules_file:
      - /etc/falco/falco_rules.yaml
      - /etc/falco/custom_rules.yaml
    # Production tuned settings
    buffered_outputs: true
    outputs_rate: 100
    max_burst: 1000
    # Alert channels
    json_output: true
    http_output:
      enabled: true
      url: "https://security-webhook.company.com/alerts"
    # Performance optimization
    base_syscalls:
      custom_set:
        - open
        - openat
        - connect
        - execve
        - clone

3. Monitoring and Alerting:

# monitoring-stack.yaml
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: container-security
spec:
  groups:
  - name: security.rules
    rules:
    - alert: CriticalVulnerabilityDetected
      expr: trivy_vulnerabilities{severity="CRITICAL"} > 0
      for: 0m
      annotations:
        summary: "Critical vulnerability in {{ $labels.image }}"
    - alert: FalcoSecurityEvent
      expr: increase(falco_events_total[5m]) > 10
      for: 2m
      annotations:
        summary: "High rate of security events detected"

4. Compliance and Governance:

# admission-controller.yaml
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionWebhook
metadata:
  name: security-policy-webhook
webhooks:
- name: security.policy.webhook
  rules:
  - operations: ["CREATE", "UPDATE"]
    apiGroups: ["apps"]
    resources: ["deployments"]
  admissionReviewVersions: ["v1"]
  clientConfig:
    service:
      name: security-webhook
      namespace: security-system
      path: "/validate"

5. Incident Response Automation:

#!/bin/bash
# incident-response.sh
case "$ALERT_TYPE" in
  "CRITICAL_VULNERABILITY")
    # Quarantine affected pods
    kubectl patch deployment $DEPLOYMENT -p '{"spec":{"replicas":0}}'
    # Notify security team
    curl -X POST "$SLACK_WEBHOOK" -d "{\"text\":\"Critical vulnerability detected in $DEPLOYMENT\"}"
    ;;
  "RUNTIME_VIOLATION")
    # Scale down suspicious workload
    kubectl scale deployment $DEPLOYMENT --replicas=1
    # Collect forensics
    kubectl exec $POD -- ps aux > /tmp/forensics-$POD.txt
    ;;
esac

Key Production Practices:

• Automated Response: Immediate containment of threats
• Continuous Monitoring: 24/7 security event monitoring
• Regular Updates: Keep vulnerability databases current
• Performance Tuning: Optimize for production workloads
• Compliance Reporting: Automated compliance documentation

20. How do you handle false positives in Falco and Trivy?

Difficulty: Expert
Answer:
False Positive Management Strategy:
1. Falco False Positive Handling:
Rule Tuning:

# Custom exception macros
- macro: trusted_containers
  condition: >
    container.image.repository in (
      gcr.io/my-company/app,
      docker.io/library/nginx,
      quay.io/prometheus/node-exporter
    )
- macro: development_namespace
  condition: k8s.ns.name in (dev, staging, test)
# Modified rule with exceptions
- rule: Write below binary dir
  condition: >
    bin_dir and evt.dir = < and open_write
    and not package_mgmt_procs
    and not trusted_containers
    and not development_namespace
  append: true

Environment-Based Filtering:

# production-rules.yaml
- rule: Sensitive File Access
  condition: >
    sensitive_file_access
    and not k8s.ns.name in (kube-system, monitoring)
    and not proc.name in (backup-agent, log-collector)
  enabled: true
# development-rules.yaml  
- rule: Sensitive File Access
  enabled: false  # Disable in development

2. Trivy False Positive Management:
Vulnerability Risk Assessment:

# .trivyignore with justification
# CVE-2023-12345 - False positive: affects Windows only, we use Linux
CVE-2023-12345
# CVE-2023-67890 - Risk accepted: Low impact, fix breaks functionality
CVE-2023-67890
# Temporary ignore until patch available
CVE-2024-12345  # TODO: Remove after Q2 2024 update

Policy-Based Ignores:

# trivy-policy.rego
package trivy
# Ignore development dependencies
ignore[msg] {
    input.package_type == "npm"
    input.file_path contains "devDependencies"
    msg := "Development dependency ignored"
}
# Ignore specific package versions
ignore[msg] {
    input.pkg_name == "lodash"
    input.installed_version == "4.17.19"
    input.vulnerability_id == "CVE-2020-8203"
    msg := "Lodash vulnerability accepted - prototype pollution mitigated"
}
# Environment-specific ignores
ignore[msg] {
    input.image_name contains "dev"
    input.severity == "MEDIUM"
    msg := "Medium severity ignored in development images"
}

3. Automated False Positive Detection:

# false-positive-analyzer.py
import json
import requests
from datetime import datetime, timedelta
class FalsePositiveAnalyzer:
    def __init__(self):
        self.whitelist_patterns = [
            # Known safe patterns
            r"kubectl.*exec.*-it.*sh",  # Interactive debugging
            r"health-check.*curl.*localhost",  # Health checks
            r"backup-job.*mysqldump"  # Scheduled backups
        ]
    def analyze_falco_alert(self, alert):
        """Analyze Falco alert for false positive patterns"""
        if self.is_known_safe_pattern(alert):
            return True, "Known safe operation"
        if self.is_development_namespace(alert):
            return True, "Development environment"
        return False, None
    def analyze_trivy_vulnerability(self, vuln):
        """Analyze Trivy vulnerability for false positive"""
        # Check if vulnerability is actually exploitable
        if self.check_exploitability(vuln):
            return False, None
        # Check if there's a workaround in place
        if self.has_mitigation(vuln):
            return True, "Mitigation in place"
        return False, None

4. Continuous Improvement Process:

# false-positive-workflow.yaml
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  name: false-positive-review
spec:
  templates:
  - name: weekly-review
    steps:
    - name: collect-alerts
      template: collect-security-alerts
    - name: analyze-patterns
      template: pattern-analysis
    - name: update-rules
      template: rule-updates
    - name: notify-team
      template: send-report

5. Metrics and Monitoring:

# Prometheus queries for false positive tracking
# False positive rate
rate(falco_alerts_total{disposition="false_positive"}[1h]) / 
rate(falco_alerts_total[1h]) * 100
# Trivy scan efficiency
trivy_vulnerabilities_total{severity="CRITICAL"} - 
trivy_vulnerabilities_total{severity="CRITICAL",status="ignored"}

Best Practices:

• Regular Reviews: Weekly false positive analysis
• Pattern Recognition: Automated detection of common patterns
• Documentation: Clear justification for all ignores
• Metrics Tracking: Monitor false positive rates
• Team Training: Educate team on proper triage procedures

21. How would you implement a zero-trust security model using Falco and Trivy?

Difficulty: Expert
Answer:
Zero-Trust Implementation Strategy:
1. Continuous Verification:

# admission-controller.yaml
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionWebhook
metadata:
  name: zero-trust-admission
webhooks:
- name: security.validation
  rules:
  - operations: ["CREATE", "UPDATE"]
    apiGroups: ["apps"]
    resources: ["deployments", "daemonsets"]
  clientConfig:
    service:
      name: zero-trust-validator
  admissionReviewVersions: ["v1"]

Zero-Trust Validation Logic:

// zero-trust-validator.go
func validateDeployment(deployment *appsv1.Deployment) error {
    // 1. Image must be scanned and approved
    if !isImageApproved(deployment.Spec.Template.Spec.Containers[0].Image) {
        return fmt.Errorf("image not approved by security scan")
    }
    // 2. Must have security context
    if deployment.Spec.Template.Spec.SecurityContext == nil {
        return fmt.Errorf("security context required")
    }
    // 3. No privileged containers
    for _, container := range deployment.Spec.Template.Spec.Containers {
        if container.SecurityContext.Privileged != nil && *container.SecurityContext.Privileged {
            return fmt.Errorf("privileged containers not allowed")
        }
    }
    return nil
}

2. Runtime Behavioral Analysis:

# zero-trust-falco-rules.yaml
- rule: Unauthorized Network Connection
  desc: Detect connections to unapproved external services
  condition: >
    outbound and not fd.sip in (approved_external_ips)
    and not fd.sport in (approved_ports)
  output: "Unauthorized network connection (dest=%fd.sip:%fd.sport proc=%proc.name)"
  priority: CRITICAL
- rule: Unexpected Process Execution
  desc: Process not in approved baseline
  condition: >
    spawned_process and not proc.name in (approved_processes)
    and not container.image.repository in (trusted_images)
  output: "Unexpected process execution (proc=%proc.name image=%container.image.repository)"
  priority: HIGH
- rule: File System Integrity Violation
  desc: Unauthorized file modifications
  condition: >
    open_write and fd.name startswith "/app"
    and not proc.name in (approved_writers)
  output: "Unauthorized file modification (file=%fd.name proc=%proc.name)"
  priority: WARNING

3. Dynamic Policy Enforcement:

# network-policy.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: zero-trust-default-deny
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          security.level: "trusted"
    ports:
    - protocol: TCP
      port: 443
apiVersion: v1
kind: ConfigMap
metadata:
  name: security-policy-config
data:
  policy.rego: |
    package kubernetes.admission
    deny[msg] {
        input.request.kind.kind == "Pod"
        input.request.object.spec.containers[_].securityContext.runAsRoot == true
        msg := "Containers cannot run as root"
    }
    deny[msg] {
        input.request.kind.kind == "Pod"
        not input.request.object.metadata.labels["security.scan.status"]
        msg := "Pod must have security scan status label"
    }

4. Continuous Compliance Monitoring:

# compliance-monitor.yaml
apiVersion: batch/v1
kind: CronJob
metadata:
  name: zero-trust-compliance-check
spec:
  schedule: "0 */6 * * *"  # Every 6 hours
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: compliance-checker
            image: compliance-scanner:latest
            command:
            - /bin/sh
            - -c
            - |
              # Verify all running images are still compliant
              kubectl get pods -A -o json | jq -r '.items[].spec.containers[].image' | \
              while read image; do
                trivy image --exit-code 1 --severity CRITICAL "$image" || \
                kubectl label pod --selector="app=$image" security.compliance=failed
              done
              # Check for runtime violations
              falco --validate-rules /etc/falco/zero-trust-rules.yaml

5. Automated Response System:

# zero-trust-response.py
class ZeroTrustResponseSystem:
    def __init__(self):
        self.k8s_client = kubernetes.client.ApiClient()
        self.threat_levels = {
            'CRITICAL': self.quarantine_workload,
            'HIGH': self.restrict_network_access,
            'MEDIUM': self.increase_monitoring
        }
    def handle_security_event(self, event):
        """Process security events and respond according to zero-trust policy"""
        threat_level = self.assess_threat_level(event)
        response_action = self.threat_levels.get(threat_level)
        if response_action:
            response_action(event)
            self.log_response(event, threat_level)
    def quarantine_workload(self, event):
        """Immediately isolate suspicious workload"""
        # Scale to zero replicas
        self.scale_deployment(event.deployment, 0)
        # Apply restrictive network policy
        self.apply_quarantine_policy(event.namespace, event.pod)
        # Alert security team
        self.send_alert("QUARANTINE", event)
    def verify_trust_boundary(self, workload):
        """Continuously verify workload trustworthiness"""
        # Check image compliance
        scan_result = self.scan_image(workload.image)
        if not scan_result.compliant:
            return False
        # Verify runtime behavior
        behavior_score = self.analyze_runtime_behavior(workload)
        if behavior_score < self.trust_threshold:
            return False
        return True

Key Zero-Trust Principles:

• Never Trust, Always Verify: Continuous scanning and monitoring
• Least Privilege Access: Minimal required permissions
• Micro-Segmentation: Granular network policies
• Continuous Monitoring: Real-time threat detection
• Automated Response: Immediate threat containment

22. Design a security incident response workflow using Falco alerts and Trivy scan results.

Difficulty: Expert
Answer:
Comprehensive Incident Response Framework:
1. Alert Correlation and Triage:

# incident-response-pipeline.yaml
apiVersion: argoproj.io/v1alpha1
kind: WorkflowTemplate
metadata:
  name: security-incident-response
spec:
  templates:
  - name: incident-triage
    inputs:
      parameters:
      - name: alert-data
      - name: source-tool
    steps:
    - name: severity-assessment
      template: assess-severity
    - name: evidence-collection
      template: collect-evidence
    - name: threat-analysis
      template: analyze-threat
    - name: response-execution
      template: execute-response
    - name: post-incident
      template: post-incident-tasks
  - name: assess-severity
    script:
      image: security/incident-analyzer:latest
      command: [python]
      source: |
        import json
        import sys
        alert = json.loads(sys.argv[1])
        # Severity scoring matrix
        severity_score = 0
        # Falco alert severity mapping
        if alert.get('source') == 'falco':
            priority_weights = {
                'EMERGENCY': 100,
                'ALERT': 90,
                'CRITICAL': 80,
                'ERROR': 60,
                'WARNING': 40
            }
            severity_score += priority_weights.get(alert.get('priority', 'WARNING'), 20)
        # Trivy vulnerability severity mapping
        elif alert.get('source') == 'trivy':
            vuln_weights = {
                'CRITICAL': 85,
                'HIGH': 70,
                'MEDIUM': 40,
                'LOW': 20
            }
            severity_score += vuln_weights.get(alert.get('severity', 'LOW'), 10)
        # Asset criticality multiplier
        if alert.get('namespace') in ['production', 'prod']:
            severity_score *= 1.5
        # Output classification
        if severity_score >= 80:
            print("P1-CRITICAL")
        elif severity_score >= 60:
            print("P2-HIGH")
        elif severity_score >= 40:
            print("P3-MEDIUM")
        else:
            print("P4-LOW")

2. Evidence Collection Automation:

#!/bin/bash
# evidence-collection.sh
INCIDENT_ID=$1
NAMESPACE=$2
POD_NAME=$3
ALERT_TYPE=$4
EVIDENCE_DIR="/tmp/incident-${INCIDENT_ID}"
mkdir -p "$EVIDENCE_DIR"
echo "Collecting evidence for incident: $INCIDENT_ID"
# Container metadata
kubectl get pod "$POD_NAME" -n "$NAMESPACE" -o yaml > "$EVIDENCE_DIR/pod-manifest.yaml"
kubectl describe pod "$POD_NAME" -n "$NAMESPACE" > "$EVIDENCE_DIR/pod-description.txt"
# Runtime information
kubectl exec "$POD_NAME" -n "$NAMESPACE" -- ps aux > "$EVIDENCE_DIR/processes.txt" 2>/dev/null
kubectl exec "$POD_NAME" -n "$NAMESPACE" -- netstat -tuln > "$EVIDENCE_DIR/network.txt" 2>/dev/null
kubectl exec "$POD_NAME" -n "$NAMESPACE" -- ls -la /tmp > "$EVIDENCE_DIR/tmp-files.txt" 2>/dev/null
# Container logs
kubectl logs "$POD_NAME" -n "$NAMESPACE" --previous > "$EVIDENCE_DIR/previous-logs.txt" 2>/dev/null
kubectl logs "$POD_NAME" -n "$NAMESPACE" > "$EVIDENCE_DIR/current-logs.txt"
# Security scan results
if [ "$ALERT_TYPE" = "vulnerability" ]; then
    IMAGE=$(kubectl get pod "$POD_NAME" -n "$NAMESPACE" -o jsonpath='{.spec.containers[0].image}')
    trivy image --format json "$IMAGE" > "$EVIDENCE_DIR/vulnerability-scan.json"
fi
# Node information
NODE=$(kubectl get pod "$POD_NAME" -n "$NAMESPACE" -o jsonpath='{.spec.nodeName}')
kubectl describe node "$NODE" > "$EVIDENCE_DIR/node-info.txt"
# Package evidence
tar -czf "$EVIDENCE_DIR.tar.gz" -C /tmp "incident-${INCIDENT_ID}"
echo "Evidence packaged: $EVIDENCE_DIR.tar.gz"

3. Automated Response Actions:

# incident-responder.py
import kubernetes
import json
import time
from datetime import datetime
from enum import Enum
class IncidentSeverity(Enum):
    P1_CRITICAL = "P1-CRITICAL"
    P2_HIGH = "P2-HIGH"
    P3_MEDIUM = "P3-MEDIUM"
    P4_LOW = "P4-LOW"
class IncidentResponder:
    def __init__(self):
        kubernetes.config.load_incluster_config()
        self.k8s_apps = kubernetes.client.AppsV1Api()
        self.k8s_core = kubernetes.client.CoreV1Api()
        self.k8s_network = kubernetes.client.NetworkingV1Api()
    def respond_to_incident(self, incident_data):
        """Execute automated response based on incident severity"""
        severity = IncidentSeverity(incident_data.get('severity'))
        response_actions = {
            IncidentSeverity.P1_CRITICAL: self.critical_response,
            IncidentSeverity.P2_HIGH: self.high_response,
            IncidentSeverity.P3_MEDIUM: self.medium_response,
            IncidentSeverity.P4_LOW: self.low_response
        }
        action = response_actions.get(severity)
        if action:
            return action(incident_data)
    def critical_response(self, incident):
        """Immediate containment for critical incidents"""
        actions_taken = []
        # 1. Quarantine affected workload
        if incident.get('deployment'):
            self.quarantine_deployment(incident['namespace'], incident['deployment'])
            actions_taken.append("Deployment quarantined")
        # 2. Isolate network traffic
        self.apply_isolation_policy(incident['namespace'], incident['pod_labels'])
        actions_taken.append("Network isolation applied")
        # 3. Preserve evidence
        self.preserve_pod_state(incident['namespace'], incident['pod_name'])
        actions_taken.append("Evidence preserved")
        # 4. Alert security team immediately
        self.send_emergency_alert(incident)
        actions_taken.append("Emergency alert sent")
        return actions_taken
    def quarantine_deployment(self, namespace, deployment_name):
        """Scale deployment to zero and label for investigation"""
        # Scale to zero
        self.k8s_apps.patch_namespaced_deployment_scale(
            name=deployment_name,
            namespace=namespace,
            body=kubernetes.client.V1Scale(
                spec=kubernetes.client.V1ScaleSpec(replicas=0)
            )
        )
        # Add quarantine label
        self.k8s_apps.patch_namespaced_deployment(
            name=deployment_name,
            namespace=namespace,
            body={
                "metadata": {
                    "labels": {
                        "security.status": "quarantined",
                        "security.incident": datetime.now().isoformat()
                    }
                }
            }
        )
    def apply_isolation_policy(self, namespace, pod_labels):
        """Apply network policy to isolate affected pods"""
        isolation_policy = kubernetes.client.V1NetworkPolicy(
            metadata=kubernetes.client.V1ObjectMeta(
                name=f"isolation-{int(time.time())}",
                namespace=namespace
            ),
            spec=kubernetes.client.V1NetworkPolicySpec(
                pod_selector=kubernetes.client.V1LabelSelector(
                    match_labels=pod_labels
                ),
                policy_types=["Ingress", "Egress"],
                # Deny all traffic
                ingress=[],
                egress=[]
            )
        )
        self.k8s_network.create_namespaced_network_policy(
            namespace=namespace,
            body=isolation_policy
        )

4. Incident Tracking and Communication:

# incident-tracker.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: incident-tracking-config
data:
  slack-webhook-url: "https://hooks.slack.com/services/..."
  pagerduty-integration-key: "..."
  jira-api-endpoint: "https://company.atlassian.net"
apiVersion: batch/v1
kind: Job
metadata:
  name: incident-notification
spec:
  template:
    spec:
      containers:
      - name: notifier
        image: incident-notifier:latest
        env:
        - name: INCIDENT_DATA
          value: |
            {
              "id": "INC-2024-001",
              "severity": "P1-CRITICAL",
              "source": "falco",
              "description": "Privilege escalation detected in production namespace",
              "affected_resources": ["deployment/web-app"],
              "actions_taken": ["Quarantine applied", "Network isolated"]
            }
        command:
        - /bin/sh
        - -c
        - |
          # Create JIRA ticket
          curl -X POST "$JIRA_API_ENDPOINT/rest/api/2/issue" \
            -H "Content-Type: application/json" \
            -d "$INCIDENT_DATA"
          # Send Slack notification
          curl -X POST "$SLACK_WEBHOOK_URL" \
            -H "Content-Type: application/json" \
            -d "{\"text\":\"🚨 Security Incident: $INCIDENT_ID\"}"
          # Trigger PagerDuty alert for P1/P2
          if [[ "$SEVERITY" =~ ^P[12] ]]; then
            curl -X POST "https://events.pagerduty.com/v2/enqueue" \
              -H "Content-Type: application/json" \
              -d "{\"routing_key\":\"$PAGERDUTY_KEY\",\"event_action\":\"trigger\"}"
          fi

5. Post-Incident Analysis:

# post-incident-analysis.py
class PostIncidentAnalyzer:
    def generate_incident_report(self, incident_id):
        """Generate comprehensive incident analysis report"""
        # Collect timeline data
        timeline = self.build_incident_timeline(incident_id)
        # Analyze root cause
        root_cause = self.perform_root_cause_analysis(incident_id)
        # Generate recommendations
        recommendations = self.generate_recommendations(incident_id)
        report = {
            "incident_id": incident_id,
            "timeline": timeline,
            "root_cause": root_cause,
            "impact_assessment": self.assess_impact(incident_id),
            "response_effectiveness": self.evaluate_response(incident_id),
            "recommendations": recommendations,
            "lessons_learned": self.extract_lessons_learned(incident_id)
        }
        return report
    def perform_root_cause_analysis(self, incident_id):
        """Analyze incident data to determine root cause"""
        # Analyze Falco alerts leading to incident
        falco_events = self.get_falco_events(incident_id)
        # Review Trivy scan history
        scan_history = self.get_scan_history(incident_id)
        # Correlate with deployment changes
        deployment_changes = self.get_deployment_history(incident_id)
        # Apply 5-whys analysis
        root_cause = self.five_whys_analysis(
            falco_events, scan_history, deployment_changes
        )
        return root_cause

Incident Response Metrics:

• Mean Time to Detection (MTTD): Average time to detect threats
• Mean Time to Response (MTTR): Average time to respond to incidents
• False Positive Rate: Percentage of false alarms
• Containment Effectiveness: Success rate of automated containment
  This comprehensive incident response framework ensures rapid, consistent, and effective handling of security incidents while maintaining detailed audit trails for compliance and continuous improvement.

Least privilege means granting containers only the minimum permissions and resources needed to function. This includes:

• User Privileges: Running containers as non-root users when possible
• Capability Dropping: Removing unnecessary Linux capabilities
• Resource Limits: Setting CPU, memory, and storage constraints
• Network Access: Limiting network connectivity to required services only
• File System Access: Using read-only file systems and minimal volume mounts
  Example:

# Instead of running as root
USER 1000:1000
# Drop all capabilities and add only required ones
RUN setcap cap_net_bind_service=+ep /app/server

Public base images can introduce several security risks:

• Vulnerable Dependencies: Images may contain outdated packages with known CVEs
• Malicious Code: Unverified images might contain backdoors or malware
• Supply Chain Attacks: Compromised upstream images can affect downstream applications
• Unnecessary Components: Bloated images increase attack surface
• Lack of Maintenance: Abandoned images won't receive security updates
  Mitigation: Use official images, verify image signatures, scan for vulnerabilities, and regularly update base images.

Privileged Mode:

• Container has access to all host devices and capabilities
• Can perform operations normally restricted to root
• Essentially removes security boundaries between container and host
• Should be avoided in production
  Unprivileged Mode (default):
• Container runs with limited capabilities
• Cannot access host devices without explicit permission
• Maintains security isolation from host system
  Example:

# Privileged (dangerous)
docker run --privileged myapp
# Unprivileged with specific capability
docker run --cap-add=NET_ADMIN myapp