Detected Issues
Last updated
Last updated
The runs on your premises to analyze DevOps tools and software projects, including source code and configurations.
The scan findings or security issues represent misconfigurations, flaws or anomalies that increase the risk of a successful software supply chain attack.
Each issue could be found by a detector, which can be thought of as the unit of analysis. Running a set of detectors over the target software project is a scan. Scans for each issue type can be analyzed separately or in a single run.
Below are the types of issues encountered in Xygeni:
A dependency is vulnerable when some programming defect or flaw can be exploited with malicious intent. Do you remember Log4J ? That dependency is not malicious, just vulnerable. Someone found a trick to exploit a flaw in the source code of the dependency that could be used to gain improper access to some resource.
Publicly known vulnerabilities are published as CVEs. Xygeni is able to scan your dependencies to find CVEs from public sources (, and among others )
A Suspect Dependency models a dependencies issue, a defect in project dependencies that may open the door to software supply-chain attacks.
A classic example is having an indirect dependency which was compromised by an actor to inject malware in the software that depends on that component. The actor may inject malicious code and indirectly attack the organizations that use the affected version(s) of the malware component.
Attacks on the Software Supply Chain often use techniques that exploit flaws in components referenced in software and dependency descriptors, package manager configurations, and other sources. Notable examples such as or Typosquatting.
A CI/CD misconfiguration is any flaw in the configuration of a tool that could allow bad actors to perform unintended operations affecting the software pipeline.
There are many systems in the software pipeline that could have a misconfiguration: management systems, build tools, package managers, registries, compilers, testing frameworks, IDEs, CI/CD systems, provisioning tools, container frameworks and orchestration tools…
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...
When a software supply chain attack occurs, the bad actors may infiltrate malicious code and unintended behaviour, open backdoors and change the software in a way that could be used as a vector for malware delivery.
Malicious Code Evidence encompasses indicators of malicious software (malware) identified through static analysis of the target software. The integration of automated analysis tools for detecting potential supply chain breaches enhances traditional software security assessments. As malicious actors employ obfuscation techniques to conceal their modifications from manual reviews, these techniques can also provide further evidence of illicit activities.
From the evidence collected, a maliciousness score for the software under analysis is calculated. With enough evidence accumulated, the analyzed software could be classified as potentially malicious.
The Malware Scanner is a tool that checks the files of the software project under analysis, and reports "evidence" according to malware detectors currently active for the policy assigned to the project. Detected evidence could be uploaded to the Xygeni platform for consolidation and for enabling response actions.
A secret in this context is any piece of information that allows an actor to gain access to a sensitive resource. Typical secrets are authentication credentials like usernames and passwords, API keys / tokens, cryptographic keys (symmetric or private), pass phrases, and many more.
Unauthorized access to sensitive information has led to significant disruptions in the software supply chain. Having hard-coded secrets in source code or configurations, particularly when under source control, is an invitation for bad actors to gain access to the organization’s sensitive resources.
Other types of information like personal or private information, business sensitive data, industrial footprints, etc... could be included in this category.
Infrastructure-as-Code or IaC is a method to provision and manage IT/Cloud infrastructure through the use of source code (IaC templates) under version control, rather than through operating procedures and manual processes.
An IaC Flaw represents a "flaw" or "defect" (a non-compliance) for a certain policy, found in an Infrastructure-as-Code (IaC) template.
A Software Supply Chain Standard / Guideline is represented by a Xygeni Standard, which contains a list of Checkpoints. A Checkpoint is a requirement that the software must match.
A checkpoint may belong to a category. Categories break down a standard into a hierarchy of different areas that represent the standard’s relevant parts.
Each checkpoint could be required or optional. A required checkpoint is mandatory and must pass for the project to be compliant with the whole standard. An optional checkpoint, on the other hand, is evaluated but does not affect the global compliance status.
Checkpoints have further metadata, like the severity (which is the impact of a non-compliant checkpoint on the risk for supply chain security), what is the explanation of the checked condition, and what needs to be done for attaining full compliance (remediation).
When a standard’s compliance assessment is evaluated, a compliance report is generated, with each checkpoint result and a global compliance status.
The checkpoint result models the result of the evaluation of a checkpoint over the project under analysis. The result has a status (pass, partial, fail, n/a or unknown) with the following meaning:
ok - The target project is compliant for the checkpoint.
fail - The target project is NOT compliant.
partial - The target project is partially (but not completely) compliant.
n/a - The checkpoint does not apply for the target project.
unknown - Checkpoint evaluation failed, result is unknown / inconclusive / uncertain.
The result indicates a compliance level on a scale from 0 to 10, where 0 denotes non-compliance, 10 represents full compliance, and values from 1 to 9 signify varying degrees of compliance.
The global compliance status is derived from the checkpoints evaluated, with this scheme:
Optional and n/a checkpoints do not influence the standard compliance status, they are ignored.
If no checkpoint was run, N/A is returned.
Otherwise, if at least one mandatory checkpoint is non-compliant or unknown, FAIL is returned.
Otherwise, if at least one mandatory checkpoint is only partially compliant, PARTIAL is returned.
Otherwise, if at least one mandatory checkpoint is compliant, PASS is returned.
If no mandatory checkpoint has a pass / partial / fail status, N/A is returned.
The global compliance level is the weighted average (with weights based on severity) of the compliance level of all the checkpoints evaluated (required and optional), with the same 0 to 10 scale, indicating how far the current status is from full compliance for the target software project.
Unusual activity events represent user actions in your tools or over critical files that are out of the typical pattern of actions for the project.
The platform offers two main types of activity monitoring to detect and respond to potential security incidents or breaches: Critical file modification and User suspect behavior.
Xygeni provides vital capabilities to help organizations enforce security procedures and detect unauthorized changes on files marked as critical.
Our platform detects any change potentially leading to Code Tampering in these files when a commit does not match the conditions that must be accomplished for the changes to be accepted.
In such situations, the system launches an alert to notify the change on a subset of the project sources deemed as critical without following the prescribed change process.
Xygeni’s policies and audit enforce best practices in access controls, multi-factor authentication requirements and role-based permissions applications to limit user access to critical systems and data.
Unusual activity detection performs continuous monitoring by collecting state changes from tools and logs and compiling usage patterns into a user behavior model.
After that learning phase, it identifies anomalies in new operations as deviations from the 'normal' user behavior modeled.
Live notifications for high-severity alerts are provided to the user, as this kind of flaw usually demands immediate action to mitigate the risk and prevent further damage.
See and for further information.
See and for further information.
See and for further information.
See and for further information.
See , and for full documentation on the supported standards and their checkpoints.
See and for further information.
See and for further information.