[Feature] Container Security Scanning with Syft and Grype

[Nitr4x]

Summary

Implement container image security scanning by integrating Syft for Software Bill of
Materials (SBOM) generation and Grype for vulnerability scanning against container images.
This extends the existing filesystem-level Syft/Grype pipeline to cover container images as
a distinct scan target type.

Problem / Motivation

Container images can bundle vulnerable OS packages, language runtime dependencies, and
third-party libraries that are invisible to source-code-level scanning. Without SBOM generation
and vulnerability analysis at the container layer, teams have an incomplete view of their
security posture and leave deployed workloads at undetected risk.

Any organisation shipping or operating containerised workloads needs a way to:

• Enumerate all software packages present inside an image (the SBOM).
• Cross-reference those packages against known CVE databases to identify exploitable vulnerabilities.
• Receive actionable reports (severity, affected package, fixed version) that integrate with
  the existing ScopeGuardian workflow.

Proposed Solution

Extend ScopeGuardian to accept a container image reference (e.g., registry/image:tag) as a
scan target and run the following pipeline:

1. Syft (prerequisite) — pull/inspect the container image and generate an SBOM in
   SCAN_DIR/results/sbom.syft.json (CycloneDX or SPDX format).
2. Grype (scanner) — consume sbom.syft.json and produce a vulnerability report at
   SCAN_DIR/results/grype-result.json. Grype must be skipped if the Syft step fails,
   consistent with the current engine execution model (engine/engine.go).
3. Reporting — surface findings through the existing ScopeGuardian reporting pipeline
   with severity filtering and ignore-state support (mirroring loader.Grype.IgnoreStates
   and loader.Grype.Exclude).
4. Configuration — add a new container scan target type in the loader config so
   container scanning is opt-in and does not affect existing filesystem scan behaviour.

Implementation touch-points:

• features/scans/grype/ — extend or add a service variant for container image SBOMs.
• loader/dto.go — add container image target fields.
• engine/engine.go — register the new container prerequisites/scanners alongside
  the existing filesystem ones.

Alternatives Considered

• Trivy: An all-in-one tool that handles SBOM and vulnerability detection in a single
  binary. Rejected because splitting Syft and Grype as separate engine steps aligns with
  the existing architecture and offers more flexibility over SBOM format and result processing.
• Snyk Container: A mature commercial option. Rejected because it requires a paid
  subscription and does not fit the open-source, self-hosted model of ScopeGuardian.
• Docker Scout: Built into Docker Desktop but tightly coupled to Docker Hub, limiting
  use with self-hosted or air-gapped registries.

Additional Context

• Syft: https://github.com/anchore/syft
• Grype: https://github.com/anchore/grype
• The engine already models Syft as a prerequisite for Grype for filesystem scans
  (engine/engine.go). This feature extends that proven pattern to container images.
• Grype scan package reference: features/scans/grype/ (service, factory, const, dto).