Known Weaknesses and Caveats

While this Trivy container is built with reliability in mind, it's important to note that it primarily focuses on scanning and reporting. There isn't an advanced validation mechanism beyond ensuring that the container builds and runs the scans correctly. Future improvements include more robust testing and validation measures.

ToDo

• Implement more comprehensive testing beyond basic functionality.
• Integrate safe testing with known vulnerable files for end-to-end testing.
• Develop a consistent reporting system for scan results.
• Experiment with and test quarantine measures for identified vulnerabilities.

Disclaimer

Understanding the scope and limitations of a vulnerability scanner like Trivy is crucial. A Trivy scan aims to increase observability and enable actions on detectable vulnerabilities, not guarantee future system security. Positive detections should prompt IT staff to consider appropriate remediation steps.

Considerations

Trivy, running as a Docker container, offers a certain level of security and obscurity. Its cryptographic signature and isolation from typical user space make it a less likely target for tampering by advanced attackers. While it includes a mode for potential quarantine actions, this feature is more theoretical. It has yet to be extensively tested in its current form. Users should exercise caution and use scan logs as a guide for manual file handling if necessary.

Usage

Create a directory for the Trivy container configuration:

mkdir -p /root/trivy/

Then edit the Docker Compose file:

nano /root/trivy/docker-compose.yml

Environment Variables and Defaults

Variable	Description	Default Value
TIMEOUT	Maximum duration for a scan	120m
SCANNERS	Scanners to be used	vuln,misconfig,secret
IGNORE_UNFIXED	Whether to ignore vulnerabilities without fixes	false
LOW_PRIORITY	Run scans with low CPU priority (nice 19)	true

Note:

By default, the container assumes a low-priority mode for scanning if the LOW_PRIORITY environment variable is not explicitly set.

docker-compose.yml

version: '3.8'

services:
  trivy:
    image: git.nixc.us/colin/trivy:production
    volumes:
      - /:/mnt:ro
      - ./log:/log
    # Uncomment and modify the following lines to customize environment variables
    # environment:
    #   TIMEOUT: "120m"  # Default scan timeout
    #   SCANNERS: "vuln,misconfig,secret"  # Scanners to be used
    #   IGNORE_UNFIXED: "false"  # Whether to ignore unfixed vulnerabilities
    #   LOW_PRIORITY: "true"  # Run scans with low CPU priority
    read_only: true
    tmpfs:
      - /tmp
    deploy:
      resources:
        limits:
          cpus: '0.50' # Limit to 50% of a CPU
          memory: 512M  # Limit to 512 megabytes

Schedule regular scans using crontab:

crontab -e

Then add one of the following cron examples.

Once a Week

To run the job every Sunday at midnight:

0 0 * * 0 /usr/bin/docker compose -f /root/trivy/docker-compose.yml up -d --pull --force-recreate trivy

Once Every Two Weeks

For a bi-weekly schedule, specify two days of the month, like the 1st and 15th:

0 0 1,15 * * /usr/bin/docker compose -f /root/trivy/docker-compose.yml up -d --pull --force-recreate trivy

Once a Month

To run the job on the first day of every month at midnight:

0 0 1 * * /usr/bin/docker compose -f /root/trivy/docker-compose.yml up -d --pull --force-recreate trivy

Notes:

• Verify that /usr/bin/docker is the correct path to your Docker binary. This path might vary.
• Replace /root/trivy with the directory path where your docker-compose.yml file is located.
• The cron jobs will update the trivy container according to the specified schedule. Ensure this aligns with your maintenance and update policies.