CI/CD Security
Last updated
Last updated
Xygeni’s Supply Chain Security protects your CI/CD pipelines by scanning configuration files, build scripts, and CI job definitions.
Supply Chain's CI/CD detectors identify deviations from security best practices and standards, providing immediate alerts on potential misconfigurations that could lead to unauthorized access or code or pipeline execution compromises.
With a robust set of rules based on the latest security advisories, Xygeni ensures every component of your pipeline adheres to the highest security protocols.
Detected issues may include improper settings in package managers, insecure build file or infrastructure configurations, or risky CI jobs or plugins, all of which are notified for rapid correction to maintain the integrity and safety of your software delivery processes.
Modern software pipelines integrate multiple tools ranging from SCM repositories and build tools to CI/CD systems and configuration management tools. Misconfigurations at these tools open the door to supply chain attacks.
Examples of misconfigurations are:
unprotected delivery code branches,
lack of code reviews,
poor access control practices like the lack of multi-factor authentication,
publicly accessible storage buckets in the cloud infrastructure,
flaws in CI pipelines, critical data not encrypted at rest,
weak password policies and non-rotated encryption keys,
... and many more
Contextualized remediation procedures are provided, so DevOps engineers can quickly fix the misconfiguration and learn how to avoid similar issues in the future.
Avoid data leakage and malicious code injection, hardening SCM repositories and CI/CD tool configurations.
The misconfigurations are detected across the tools in the cycle chain, from development items like code repositories, build tools, CI systems to operations at IaC templates, container images in registries, or cloud platforms.
Detects misconfigured resources in code and vulnerable images before deploying to your runtime environment.
Here’s an integration of the supported systems into the summary of key misconfiguration detectors for Xygeni:
Enforce appropriate permissions and secure configurations across CI/CD tools and workflows, specifically tailored for platforms like GitHub, GitLab, Azure DevOps, Bitbucket, CircleCI, and Jenkins.
Verify the integrity of build processes and prevent unauthorized code or pipeline changes, with specific checks for each platform to ensure compliance and security.
Monitor for unusual activities and ensure encrypted storage and handling of secrets across all supported CI/CD platforms.
Apply best practices in container configurations, such as avoiding running as root and ensuring secure file operations across various CI environments, including Jenkins and CircleCI.
Maintain secure connections by enforcing HTTPS for remote repository access and ensuring proper version control on platforms like GitHub, GitLab, and Azure DevOps.
Support compliance with key standards like CIS, NIST, and OpenSSF, ensuring security policies are adhered to across all integrated platforms.
Secure source code management practices, including enforcing MFA, signed commits, and code review protocols, particularly on platforms like GitHub, GitLab, and Bitbucket.
Detect and prevent insecure webhook configurations, unprotected branches, and insecure dependencies across all supported systems. • Monitor and validate security policies, ensuring continuous compliance and signed releases within the integrated ecosystem.
To accomplish these functionalities, Xygeni provides a Scanner and a Web UI to view the results.
The process of building and deploying modern software is complicated. The attack surface is wide: compilers, source code repositories and tools (build, package managers, artifact registries, testing, security scanners) can be affected to let code / configuration tampering pass undetected, or to implant malicious behavior.
Software artifacts are often opaque blobs that can’t easily be inspected for security. It is easier to reason about how they came to be (provenance), rather than what is in them. So what can be done to harden the build & deploy system? How can an organization attain tamper-proof builds?
Tamper-proof builds, where the focus is to prevent or detect tampering during the build is hard to achieve and needs a strong hardening of the build platform, which is not always possible. Having signed attestations generated by a hosted build platform is a previous stage, with focus on detecting tampering after the build. For software attestations the following is necessary:
(1) generating “attestations”, authenticated metadata about software artifacts produced by each build step, linked with the inputs (“materials”). Each step in the pipeline must conform with a pipeline layout, where an owner defines the steps and conditions to be fulfilled.
(2) storing the attestations in a kind of evidence repository or "ledger" that keeps evidence preserved.
(3) providing verification capabilities downstream so a client can verify the integrity of the artifact(s) from the ledger before installing / running the artifact(s).
Xygeni checks compliance of your software with Software Supply-Chain Security Standards and Guidelines.
Each standard is composed of a set of checkpoints that are checked against the software project under analysis.A checkpoint belongs to a category, and could be required or optional.The result tells us if the project complies with the standard, with a compliance level.
TBD
See and
See and, more specifically, for instructions on how to execute an Open Source scan.
Xygeni provides the infrastructure for generating software attestations in the software pipelines and verifying them downstream when needed. See for further information.
See
Xygeni runs on software projects and DevOps tools for compliance assessment, under standards and guidelines like OpenSSF Scorecard or CIS Software Supply Chain Security or , among others.
See for more information.
