Artifact Analysis

Introduction

Artifact Analysis is the third pillar of creation. It is responsible for performing a comprehensive analysis of built software artifacts to detect vulnerabilities, validate software composition, and ensure compliance with security and quality standards.

The Artifact Analysis Pillar aims to:

• Identify Vulnerabilities: Detect known security issues in the built artifacts using vulnerability databases.
• Generate SBOMs: Create Software Bill of Materials for transparency and compliance.
• Ensure Compliance: Verify that artifacts meet organizational and regulatory security standards.
• Validate Functionality: Confirm that the software behaves as expected in a controlled environment.

Components

The Artifact Analysis Pillar comprises two main types of analysis:

Static Artifact Analysis

Examines the artifacts without executing them to identify potential security issues.

Tools Used

Grype

Scans container images for vulnerabilities. it runs in a dedicated job that outputs detailed vulnerability reports.

Trivy

Provides comprehensive scanning of container images, filesystems, and SBOM generation. It runs in its own job, generating reports in various formats (JSON, SARIF).

Syft

Generates SBOMs for container images and filesystems in formats like CycloneDX and SPDX. It runs concurrently with other static analysis tools.

ClamAV (Rampart)

Anti-virus scanning for artifacts.

NeuVector

Provides deep security and compliance scanning of container images.

OSCAP (Pinnacle)

Performs compliance checks against security policies or benchmarks

Dynamic Artifact Analysis

Tests the artifacts in a runtime environment to uncover issues that only appear during execution.

Tools Used

OWASP ZAP

Scans web applications for vulnerabilities during execution.

• Function: Scans the running web application for vulnerabilities.
• Execution: Deploys the application in a controlled environment and performs active scanning.
• Configuration: Scan settings can be customized via configuration files included in the project.

Cypress

Runs end-to-end tests to validate application functionality.

• Function: Executes end-to-end tests to validate application functionality.
• Execution: Runs tests defined in the project's cypress directory.
• Configuration: Test parameters and environment variables can be set as needed.

Unit Tests and Code Coverage

• Function: Validates individual units of code and measures test coverage.
• Execution: Runs as part of the dynamic analysis stage if tests are defined.
• Configuration: Requires test scripts and configuration files in the project.

note

Unit Tests and Code Coverage Analysis are language-specific.

Running Scans

The analysis jobs are designed to run in parallel to optimize efficiency and reduce overall pipeline time. Here's an overview of the process:

1. Preparation: The pipeline utilizes the container image built in the previous stage for both static and dynamic analyses.
2. Static Analysis Execution: Multiple static analysis tools run simultaneously to scan the artifact for vulnerabilities without executing it.
   • Grype and Trivy perform vulnerability scans on the container image.
   • Syft generates SBOMs for the artifact.
   • ClamAV (Rampart) conducts anti-virus scanning.
   • NeuVector performs in-depth security and compliance scanning.
   • OSCAP (Pinnacle) checks the artifact against security benchmarks.
3. Dynamic Analysis Execution: In parallel with static analysis, dynamic analysis tools deploy the artifact in a controlled environment and run tests.
   • OWASP ZAP scans the running application for web vulnerabilities.
   • Cypress executes end-to-end tests to validate application functionality.
   • Unit Tests and Code Coverage analyses are conducted if applicable.
4. Reporting: Each tool compiles its respective reports, logs, and SBOMs. These are processed concurrently as tools finish their executions.
5. Evaluation: The pipeline evaluates each report against predefined security and compliance thresholds.
   • Jobs may fail if vulnerabilities exceed acceptable levels.
   • Results are aggregated for a comprehensive view of the artifact's security posture.

Accessing Reports

After the pipeline runs:

1. In your GitLab project, go to Build > Artifacts.
2. In the Artifacts section, you can download the reports and SBOMs generated by the pipeline.

note

The reports will not be available until the publishing stage is complete.

Evaluating Results

• Review the vulnerability reports to identify and prioritize issues.
• Address critical and high-severity vulnerabilities promptly.
• Re-run the pipeline after fixes to ensure vulnerabilities have been resolved.

Suppressing or Ignoring Findings

This document serves as a guide on how you can manage and ignore certain vulnerabilities discovered by the security scanning tools. This may happen when you do not want the output of certain vulnerabilities due to various reasons such as false positives, they do not apply to your environment, there is no known fix or any other reason. However, you must exercise caution when ignoring vulnerabilites by conducting extensive research about the particular vulnerability and providing sufficient context for future references.

Static Analysis Tools

Grype

Grype allows you to ignore vulnerabilities by configuring ignore rules in your grype configuration file. This prevents grype from reporting any vulnerability matches that meet any of the criteria specified in the ignore rule.

Follow the steps below to ignore vulnerabilities in your project

1. Create or edit the grype.yaml file at the root of your project or home directory which will allow you specify which vulnerabilities to ignore
2. Add ignore rules using the ignore section to specify which vulnerabilities to suppress by specifying rules such as vulnerability ID or package, etc.

ignore:
  - vulnerability: CVE-2008-4318
    reason: " Redhat has no known fix for this vulnerability or This vulnerability is not relevant to this environment"
  - package: "libpackage@1.2.3"
    reason: " This is not applicable to this environment"

3. Rerun the scan to validate the ignored vulnerabilities are no longer displayed in Grype's output

Annotating Vulnerabilities in Grype

When suppressing vulnerabilities in Grype, it is helpful to provide additional details and context about a detected vulnerability using annotations. This is important for documentation and audit purposes by providing more information about why certain vulnerabilities were not fixed.

Example with annotation:

ignore:
  - vulnerability: CVE-2008-4318
    reason: "False positive, not applicable in this environment"
    x-reference: "Any custom yaml key that could be used to provide more information about the vulnerability for easy reference and transparency"

Please refer to Grype documentation for more infortion on ignoring vulnerabilities

Trivy

Trivy allows you to ignore vulnerabilities by configuring a .trivyignore or .trivy.yaml file. This allows Trivy to skip any vulnerabilities listed in the files.

How to ignore vulnerabilies in Trivy**

Follow the steps below to ignore or filter vulnerabilities for your project.

1. Create or edit the .trivyignore file at the root of your project directory to specify which vulnerabilities to ignore.
2. Add the vulnerability IDs you want to suppress to the .trivyignore file. Trivy will automatically read this file when running scan.

Example .trivyignore file:

# Vendor won't fix this vulnerability. Severity is low
  CVE-2008-4318
  CVE-2008-4319
  # Does not apply to this environment
  CVE-2024-34587

3. Rerun the scan to validate the ignored vulnerabilities are no longer displayed in Trivy's output and making sure the --ignorefile flag is added to the command

Annotating Vulnerabilities in Trivy**

While we can use a .trivyignore file to suppress vulnerabilities in Trivy, a .tryignore.yaml file allows for more detailed configuration and context about the vulnerability by using annotations or filters. You can set IDs separately for vulnerabilities, misconfigureations, secrets or licenses in your .trivyignore.yaml as see in below:

Example .trivyignore.yaml file

vulnerabilities:
  - id: CVE-2022-40897
    paths:
      - "usr/local/lib/python3.9/site-packages/setuptools-58.1.0.dist-info/METADATA"
    statement: Accept the risk
  - id: CVE-2023-29491
    expired_at: 2023-09-01 # e.g Expected date when patch would have been applied

misconfigurations:
  - id: AVD-DS-0001
  - id: AVD-DS-0002
    paths:
      - "docs/Dockerfile"
    statement: The image needs root privileges
secrets:
  - id: aws-access-key-id
  - id: aws-secret-access-key
    paths:
      - "foo/bar/aws.secret"

Please refer to Trivy documentation for more information.

Dynamic Analysis Tools

Cypress

Cypress is a powerful end-to-end testing framework used for testing web applications. Sometimes, when conducting your tests, you may want to ignore or skip certain tests or files for various reasons. Cypress provides various methods through which you can skip specific files or directories during testing such as using the Cypress configuration file - cypress.config.js for JavaScript apps or cypress.config.ts for TypeScript apps. You can provide configuration options for either E2E or Component Testing by creating e2e and component objects inside your Cypress configuration.

note

That the ignoreTestfiles option was replaced with excludeSpecPattern from Cypress 10. Follow the instructions below to ignore files from cypress testing using the Cypress configuration file

1. Locate the cypress configuration file (cypress.config.js or cypress.config.ts) at the root of your project. This file is automatically created when Cypress is first initialized.
2. Modify the configuration file and add the path to the tests or files you want to exclude using the excludeSpecPattern option

Example cypress.config.js

{
  component: {
    excludeSpecPattern: "path/to/**/*.js"
  },
  e2e: {
    excludeSpecPattern: "other/path/to/**/*.js"
  }
}

3. Rerun the tests to make sure that the excluded tests are ignored.

Please refer to Cypress Official Documentation for more information on excluding specific files from tests.