Goal Summary:

Implement vulnerability scanning support for PHP, Rust applications and dependencies within container images. This enhancement will ensure comprehensive coverage for a wider range of customer workloads, directly addressing competitive gaps and enhancing the value of the image vulnerability monitoring feature.

Goals and Expected User Outcomes:

The primary goal is to provide accurate and timely vulnerability identification for these new language ecosystems.

• Primary User Type/Persona: Security Analyst, DevSecOps Engineer, and Platform Security Manager.

• Observable Functionality:

• • The vulnerability scanner will successfully detect and parse package manifest files (e.g., PHP's composer.lock, Rust's Cargo.lock, and Go's dependency information) within container images.

• • The scanner will match detected packages against relevant vulnerability databases (e.g., NVD, language-specific feeds) for PHP, Rust, and Go.

• • Vulnerability findings for PHP, Rust, and Go packages will appear in the existing Vulnerability Reports, Risk Scores, and Policy Enforcement features alongside existing language support (like Python, Java, etc.).

• • Users will be able to filter and search for vulnerabilities specifically related to these new languages in the UI.

• Expanded Existing Features: This expands the core Image Vulnerability Scanning and related reporting, alerting, and policy enforcement capabilities.

Acceptance Criteria

Functional Requirements

• The vulnerability scanner must successfully parse package data and dependencies for the following language ecosystems when present in a container image:

• • PHP: Support for packages managed by Composer (using composer.lock or similar files).

• • Rust: Support for packages managed by Cargo (using Cargo.lock).

• The system must correctly link detected packages to vulnerability data from relevant upstream feeds for each language.

• Vulnerability severity, description, and remediation information for PHP, Rust, and Go must be accurately displayed in the user interface.

• The feature must support scanning packages installed via OS-level package managers if they are part of the base layer of the image.

Nonfunctional Requirements (NFRs)

• Performance: The addition of new language scanners must not increase the overall image scan time by more than 10% for images containing these dependencies.

• Scalability: The new scanning logic must be scalable to handle thousands of images and a large number of dependencies without degradation in performance.

• Maintainability: The implementation should leverage a modular architecture, ideally using Claircore modules, to facilitate the addition of future languages and updates to existing feeds.

• Reliability: The scanner must maintain an accuracy rate of over 95% (correctly identifying known vulnerable packages) compared to industry-leading open-source scanners (like Trivy).

• Security: All vulnerability feeds used for the new language support must be regularly updated and trusted.

Success Criteria or KPIs Measured

• Coverage/Adoption: 10% of all scanned container images contain successfully identified PHP, Rust, dependencies within 90 days of launch.

• Competitive Parity: The official supported languages matrix must be updated to include PHP, Rust, and Go, effectively closing the stated competitive gap against rivals like Trivy.

• Usage: Weekly Active Users of the vulnerability reporting feature increases by 5% as new language teams adopt the tool.

• Customer Satisfaction: The specific customer, confirms that the inclusion of these languages satisfies their Proof of Concept (PoC) requirements.

Use Cases

Main Success Scenario: Scanning a PHP Application Image

1. A DevSecOps Engineer pushes a new PHP application container image to the registry. This image contains a composer.lock file.

1. The vulnerability scanner automatically initiates the scan upon image push.

1. The new PHP scanning module detects the composer.lock file, reads the list of PHP package dependencies (e.g., Symfony, Laravel).

1. The scanner cross-references these dependencies against its PHP vulnerability feed.

1. A high-severity CVE found in a third-party Composer package is identified.

1. The platform generates an alert, and the finding is displayed on the image's vulnerability report, prompting the engineering team to update the vulnerable dependency.

Out of Scope (Optional)

• Support for non-package-manager dependency inclusion (e.g., manually compiled and linked C/C++ libraries used by Rust or Go).

• Run-time vulnerability analysis (focus is on static image analysis).

• Creating a proprietary vulnerability feed; the feature will leverage and integrate with existing public feeds.