Detected Issues

The Xygeni Scanner 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 the software platform being the target of a successful software supply chain attack.

Each issue could be found by a detector, which can be thought as the unit of analysis. Running a set of detectors over the target software project is a scan. Scans for each issue kind can be analyzed separately or in a single run.

The following are the issue kinds in Xygeni.

Vulnerable Dependencies

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 (NIST's NVD, GitHub Advisory Database and OSV among others )

See Open Source Security (OSS), Dependency Scanner and Dependency Analyzers for more details.

Suspect Dependencies

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 uses the affected version(s) of the malware component.

Attacks to the Software Supply Chain often use techniques that exploit flaws in components referenced in software and dependencies descriptors, package manager configurations, and other sources. Attack patters like Dependency Confusion or Typosquatting even deserve a name.

See Open Source Security (OSS) and Suspect Dependencies Scanner for more details.

CI/CD Misconfigurations

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: Source code managers, build tools, package managers and 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.

See Software Supply-Chain Security (SSCS) and CI/CD Scanner for further information.

Malicious Code Evidence

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 comprises indicators of malicious software (malware) that are discovered analyzing statically the target software. Analyzing software for potential supply chain breach complement software security reviews with automation. And as the adversaries try to hide their changes from human review they use obfuscation techniques that in fact could serve as additional evidence of wrongdoing.

From evidence collected, a maliciousness score for the software under analysis is computed. 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 "evidences" according to malware detectors currently active for the policy assigned to the project. Detected evidences could be uploaded to Xygeni platform for consolidation and for enabling response actions.

See Code Security (CS) and Malware Scanner for further information.

Hardcoded Secrets

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.

Secrets gained by bad actors are the cause of major attacks to the software supply chain. Having hardcoded secrets in software source code or configurations, particularly when under source control, is an invitation for bad actors to gain access to organization’s sensitive resources.

Other type of information like personal or private information, business sensitive data, industrial footprints, etc. could be included in this category.

See Secrets Security and Secrets Scanner for further information.

IaC Flaws

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.

See IaC Security and IaC Scanner for further information.

Compliance failures

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 the 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.

Checkpoint has further metadata, like the severity (which is the impact of a non-compliant checkpoint on the risk for supply chain security), what is the meaning of the checked condition, and what needs to be done for attaining full compliance.

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 provides a compliance level in the 0 …​ 10 range, with 0 = not compliant, 10 = fully compliant, and 1 …​ 9 the level of partial compliance attained.

The global compliance status is derived from the checkpoints evaluated, with this scheme:

• Optional and n/a checkpoints do not influence in 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 …​ 10 range, telling us how far is the current status from full compliance for the target software project.

See Software Supply-Chain Security (SSCS), Compliance Scanner and Software Supply Chain Standards for full documentation on the supported standards and their checkpoints.

Unusual Activity Events and Anomaly Detection

Unusual activity events represent user actions in the tools or over the critical files that are out of the typical pattern of actions learned 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.

Critical File Modifications (Code Tampering Prevention)

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.

See Anomaly Detection and Code Tampering Scanner for further information.

Suspect Behavior (Anomaly Detection)

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 Anomaly Detection and Xygeni Sensors for further information.