We take security seriously. If you discover a security vulnerability, please follow these steps:

Security vulnerabilities should not be disclosed publicly until a fix is available.

Send details to: [your-security-email@example.com]

Include:

• Description of the vulnerability
• Steps to reproduce
• Potential impact
• Suggested fix (if available)

• Initial Response: Within 48 hours
• Status Update: Within 7 days
• Fix Timeline: Depends on severity
  • Critical: 1-3 days
  • High: 1-2 weeks
  • Medium: 2-4 weeks
  • Low: Next regular release

1. Keep Tools Updated

   • Regularly rebuild with latest versions
   • Monitor security advisories for installed tools
   • Update ARG versions in Dockerfile

2. Credentials Management

   • Never commit credentials to the repository
   • Use git-crypt for encrypted secrets
   • Use environment variables or Azure Key Vault
   • Configure .gitignore properly

3. Container Registry

   • Images are published to the GitHub Container Registry, public and anonymously pullable
   • Every build is scanned by Trivy, with findings reported to the Security tab
   • Every published image carries an SBOM and Sigstore-signed SLSA build provenance - verify before use (see below)
   • CI authenticates with the repository's own GITHUB_TOKEN; there are no registry credentials to store or rotate

4. Volume Mounts

   • Be careful with bind mounts
   • Don't mount sensitive host directories
   • Use named volumes for persistence

5. Network Security

   • Limit exposed ports
   • Use network policies in Kubernetes
   • Implement least-privilege access

1. Dependencies

   # Verify checksums
   sha256sum -c <checksum-file>
   
   # Pin versions
   pip install package==version

2. Secrets in Code

   • Never hardcode credentials
   • Use environment variables
   • Scan code for secrets before commit
   • Use pre-commit hooks

3. Terraform/Terragrunt

   • Use remote state with encryption
   • Enable state locking
   • Don't commit .tfstate files
   • Use Azure Key Vault for secrets

4. Docker

   • Don't run containers as root
   • Scan images for vulnerabilities
   • Use minimal base images
   • Remove unnecessary packages

• tflint: Terraform linter and security scanner

  tflint --init
  tflint

• checkov: IaC security scanning

  checkov -d .
  checkov -f main.tf

• git-crypt: Transparent file encryption

  git-crypt init
  git-crypt add-gpg-user <key-id>

Consider adding:

• trivy: Container vulnerability scanner
• SOPS: Secrets encryption
• Vault: HashiCorp Vault for secret management
• Aqua Security: Container security platform

# Scan Terraform
tflint
checkov -d terraform/

# Check for secrets
git diff | grep -i "password\|secret\|key"

# Validate Ansible
ansible-playbook --syntax-check playbook.yml

Confirm an image was built by this repository's workflow, and not by someone else:

gh attestation verify oci://ghcr.io/dbhq-uk/devcontainer-devops:latest \
  -R dbhq-uk/devcontainer-devops

Inspect its SBOM:

docker buildx imagetools inspect ghcr.io/dbhq-uk/devcontainer-devops:latest \
  --format '{{ json .SBOM }}'

Scan it yourself:

trivy image --scanners vuln --severity HIGH,CRITICAL \
  ghcr.io/dbhq-uk/devcontainer-devops:latest

• All tools run as vscode user (non-root)
• Docker requires group membership for socket access
• Kubernetes config requires proper RBAC

• Container needs internet for tool downloads during build
• Runtime may need cloud provider access
• Configure firewalls appropriately

• Named volume persists between container restarts
• Bind mounts expose host filesystem
• Be cautious with sensitive data

This container aims to support:

• CIS Docker Benchmarks
• NIST Cybersecurity Framework
• SOC 2 compliance requirements
• GDPR data protection

• Git history tracks all changes
• GitHub Actions provides build logs, and build provenance links each published image back to the commit and workflow that produced it
• Enable logging for compliance

• Docker Security Best Practices
• Kubernetes Security
• Azure Security
• Terraform Security
• OWASP Top 10

This devcontainer is provided as-is for development purposes. Organizations should:

1. Conduct their own security assessments
2. Implement additional controls as needed
3. Follow their security policies
4. Regularly update and patch
5. Monitor for vulnerabilities

For security concerns: [your-security-email@example.com]

For general questions: Use GitHub Issues

Last Updated: 2025-11-21