Skip to main content
Version: 6.12.0

Code Analysis And Artifact Build

Introduction​

Code Analysis & Artifact Build is the second pillar of creation and is responsible for static code analysis, and building the artifacts (Container Image) required for the subsequent stages of the pipeline.

Purpose​

The Code Analysis & Artifact Build Pillar aims to:

  • Static Code Analysis:

    • Credential Search: Scan for hardcoded credentials and secrets in the codebase.
    • Infrastructure as Code & Configuration as Code (CaC) Validation: Validate IaC and CaC files for security and compliance.
    • Dependency Vulnerabilities: Identify vulnerabilities in dependencies.
    • Code Quality: Detect potential security vulnerabilities, code smells, and bugs in the source code.
    • Code Linting: Enforce coding standards and best practices.

  • Artifact Build

    • Software Artifacts:
      • Container Image: Build a container image for deployment.
      • Package: Create a package for distribution.
      • Library: Compile libraries for reuse.

Key Components​

The Code Analysis & Artifact Build Pillar comprises two main components:

Static Code Analysis​

Performs a comprehensive analysis of the source code to identify security vulnerabilities, code smells, and bugs. The analysis jobs are designed to run in parallel to optimize efficiency and reduce overall pipeline time.

  • Tools Used:
    • Credential Search:
      • Semgrep: A static Analysis tool that efficiently scans code for secrets and credentials with customizable rules and patterns. It uses language specific rulesets to scan the code. Currently, we have configured rulesets for Java, Javascript and Python. More rulesets will be added over time.
      • TruffleHog: Thoroughly searches for secrets in the codebase, including historical commits, to uncover hidden vulnerabilities.
    • Infrastructure as Code (IaC) & Configuration as Code (CaC) Validation:
      • Checkov: Thoroughly scans IaC and CaC files to identify security vulnerabilities and compliance issues.
      • Hadolint: Analyzes Dockerfiles to ensure adherence to best practices and detect security issues.
    • Dependency Vulnerabilities:
      • OWASP: Scans dependencies for known vulnerabilities.
      • Malcontent Discovers supply-chain compromises.
    • Code Quality:
      • SonarQube: Analyzes code for security vulnerabilities, code smells, and bugs.
    • Code Linting:
      • MegaLinter: Enforces coding standards and best practices across multiple languages.

Artifact Build​

This is where source code is compiled, packaged, and transformed into a deployable artifact, like a JAR file or container image, ready for testing and deployment in subsequent stages.

This stage typically involves tasks like:

  • Downloading dependencies.
  • Installing tools.
  • Compiling code.
  • Packaging the application.
  • Resolving dependencies.
  • Bundling assets.

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.

Semgrep​

Semgrep is a great static analysis tool that helps to detect vulnerabilities in your code and enforce code standards. It also allows you to exclude specific files or directories from being scanned and would therefore not generate findings for the ignored files. Semgrep has various ways to exclude files and directories from its scan.

The .semgrepignore which works similar to the .gitignore file is the most recommended method to ignore files and directories from Semgrep scan. Follow the steps below to setup the .semgrepignore file:

  1. Create or edit the .semgrepignore file in the root directory of your project.
  2. Add patterns for files or directories you want to ignore.

Example .semgrepignore file

# Ignore a specific file
secrets_config.yaml

# Ignore all files in a specific directory
tests/
node_modules

# Ignore files with a specific extension
*.log
*.bak
  1. Rerun the scan and validate that Semgrep does not generate a finding for the excluded files/directories.

Please refer to Semgrep documentation for more information on excluding files and directories from Semgrep Scan.

Malcontent​

Malcontent is a powerful tool for supply chain attack detection that offers features like differential analysis and malware scanning.

More information can be found in the Official Github documentation

Hadolint​

Hadolint is a widely used linter for Dockerfiles to enforce best practices and detect potential security issues in your docker images. Hadolint provide several ways to suppress or ignore specific findings for reasons such as false positives or because they are not relevant for your use case, permitting you to customize the linting process to suit your needs . This guide will walk you through how to suppress hadolint findings using the configuration file.

  1. Create or edit the .hadolint.yaml file at the root of your project
  2. Add the ignore rules, files or directories you want to exclude from the scan

Example .hadolint.yaml ignore rule. The rules listed in the ignored section below will ignore any violation whose rule is explicitly ignored for the entire project.

ignored:
  - DL3008 # Pin versions in apt-get install
  - DL4006 # Use SHELL to change default shell

Example .hadolint.yaml ignore file. The configuration below will exclude the Dockerfile.dev and tests/Dockerfiles from the scan.

ignored:
  - Dockerfile.dev
  - tests/Dockerfile
  1. Rerun the scan to validate that the ignored rules or files are longer displayed in the output.

Additionally, you can customize the severity of specific rules by overriding them instead of completely ignoring the rule.

Example of rule override.

override:
error:
  - DL3012: warning # Change severity from error to warning
  - DL3001
  - DL3002
warning:
  - DL3042
  - DL3033
info:
  - DL3032
style:
  - DL3015

For more information, please refer the Hadolint official documentation

Sonarqube​

Sonarqube allows you you suppress, whitelist or ignore specific vulnerabilities for your project due to false positives or when accepting the risk. This can be set in the Sonarqube UI or the appropriate configuration file. The Sonarqube docs provides various methods to suppress vulenrabilities such as using inline comments or suppress warnings in the code, exclude files or directories using the sonar-project.properties file. The steps below outlines how you can suppress Sonarqube findings via the UI and sonar-project.properties:

  1. Suppress issues in Sonaqube UI. Sonarqube also permits manual suppression via the UI by markings issues as False Positive or Won't Fix. This can be done by following the steps below;
  • Log in to your Sonarqube dashboard
  • Navigate to Projects --> Your Project --> Issues
  • Find the issue you want to suppress and select the "Won't Fix" or "False Positive" button to suppress it.
  1. Excluding files or directories from scans at the project level. You can configure the scope for exlusions or inclusions in the sonar-project.properties file

Example sonar-project.properties​

sonar.test.inclustions = src/**/test/**/*
sonar.exclusons=src/**/test/**/*

Please refer to Sonarqube documentation to explore other methods to suppress files from Sonarqube scans.

MegaLinter​

MegaLinter is a powerful linting tool that enforces coding standards and best practices across multiple languages. One of its useful feautures is its ability to customize linting behavior using variables which allows the developer to modify the .mega-linter.yml file and as disable linters, rules or specific files.

Please follow the steps below to configure MegaLinter using the .mega-linter.yml file to meet your project needs:

  1. Locate the .mega-linter.yml file which should be automatically created at the root of your project. Create one if the file does not exist

  2. Modify the file. You can ignore or disable entire linters or rules for specific linters or files. Below are some examples.

# Disable entire linters globally

Disable:
  - JAVASCRIPT_ESLINT
  - PYTHON_PYLINT

# Disable specific linters

DISABLE_LINTERS:
  - PHP_PHPSTAN
  - JAVASCRIPT_STANDARD
# Lint specific files or exclude specific or folders

FILTER_REGEX_INCLUDE:
  - src/

  # Exclude specific files or folders from linting

  # FILTER_REGEX_EXCLUDE:
  - test/.*\.js

Please refer to the official MegaLinter documentation more information on linting configurations.