Policies
Last updated
Last updated
A Xygeni policy lays out the set of rules, practices, checks and processes aimed at hardening your software infrastructure for controlling the risk of supply chain attacks. Each policy defines acceptable and unacceptable behaviors, which detectors should be in place, and what is the impact (based on risk scoring) when security issues are introduced.
A software project under analysis has a policy assigned, which could be more or less strict according to organizational criteria. The policy in effect is downloaded at scan time or when raw activity data is received from Xygeni sensors.
The Xygeni platform provides a default policy, tailored to cover a common assessment of the software supply chain security for most organizations.
To access to this section you must got to Settings >> Policies.
Xygeni provides three initial policies that could be used directly or as a starting point for defining custom organization policies:
strict, where most of the security controls available are enabled. At the cost of forcing teams to follow rigorous procedures for certain assets in the software infrastructure, it offers the highest level of protection, typically for highly sensitive software projects.
default, a good trade-off between security and ease-of-use. Many controls are enabled, with only the most stringent but not essential controls disabled. Recommended for important software projects that are used by customers and other third-parties.
loose, with only the most critical controls enabled. Best for ease-of-use, typically relevant for internal projects with no external users.
Any Xygeni project has an associated Policy. If not explicitly associated, a new project will be associated to the policy tagged as Default policy.
You can choose which policy will be the default among the existing ones (initial or custom policies). To do it, just select a policy and click on Set as default button.
Please note, that changing the default policy to another will not change the association for already existing projects, that will only apply to new projects.
Initial policies may change according to Xygeni decission. Thus, take in mind that associating an initial policy to a project can vary the results upon modification by Xygeni.
If you want to keep an stable policy, create a Custom Policy
Your organization may have different software supply chain security (SSCS) requirements, according to the importance of the assets to protect, like software projects and their underlying build & deploy infrastructure. Before configuring a custom Xygeni policy, you must first determine which is the depth of the security controls you want to implement and enforce:
Which is the SSCS framework your organization adopted? Examples like the CISA/ESF Securing the Software Supply Chain - Recommended Practices Guide for Developers
How changes in source repositories should be done to limit the risk of code tampering? This implies how commits should be done, how changes or branch merges are reviewed or approval, and how modification on critical files should be performed.
How third-party software (components, container images, binaries…) and extensions/plugins in tools of the software infrastructure should be verified.
How the build systems and their incarnations (CI/CD systems) and tools (build, packaging, testing, linting, security analyzers, code & documentation generation) should be protected to avoid breaches.
How to document the results of the build/deploy processes, via bill-of-materials and attestations, and the process of delivering them to the end users for validation.
How the software delivery should ensure that produced software artifacts are placed in the distribution hubs so tampering in between could be avoided or at least integrity violations could be detected by end-users before executing the software.
Creating a Custom Policy follows the approach "save as..".
This means that once you have selected a policy , after modifying any aspect of the policy the Save button will be enabled, so you can either save the current policy or create a new one (providing a new policy name).
Clicking on Statistics will show to you detailed information about ;
Active detectors
Compliance standards
Associated projects to the selected policy
A policy is just a set of configured detectors. So for any selected detector you can :
modify the severity (critical, high, low info)
activate /deactivate the detector
Available detectors are grouped by type in several tabs (secrets, CI/CD, IaC, etc.) . Go to the appropriate tab to find all associated detectors.
After modifying any detector of a policy the Save button will be enabled, so you can either save the current policy or create a new one (providing a new policy name).
