From Chaos to Clarity: Navigating Policy Engine for Compliance

All Posts

Welcome back to the second part of our blog series, where we delve deeper into the potent capabilities of Valint. In this article, we’ll focus on Valint’s policy engine and its pivotal role in assuring compliance throughout your supply chain.
In our previous blog post, we provided an overview of Valint’s design principles.

How the Policy Engine Works

Valint’s policy engine operates on a set of rules organized into policies verified against evidence collected from the supply chain. Let’s break down its key components:

Evidence: Immutable objects that are intended to be consumed automatically by the policies. These objects contain metadata needed to enable policy enforcement and to meet compliance requirements. Evidence content includes metadata about artifacts, events, and settings, but can also collect actual reports, configurations, or scans. Evidence may come in both a signed and unsigned form. We suggest following the Intoto attestation spec utilizing the signed attestation and unsigned formats, respectively.

  • Attestations (AKA verifiable signed evidence): Verifiable evidence linked to a specific environmental context, conveying trust using some form of PKI signatures.

Policies: These define the requirements your supply chain must meet, covering various aspects such as validation, compliance details, and the final verdict on evidence. As an example, the organization could have an “Container Image policy”

Policy Rules: Policies consist of rules, each representing a specific compliance check. Examples include the verification of signatures and identities, verification of SBOM components, verification of absence of critical vulnerabilities. Following the previous example, the “Container Image policy” could consist of the following rules:

  • Enforce Image Signing.
  • Warn on image not complaint with specific labels.

Bundles: Collections of policies and rules that can be conveniently referenced as a whole. Bundles provide a modular and organized way to manage and apply sets of policies as code. Scribe default policy bundle is published under https://github.com/scribe-public/sample-policies, feel free to refer to it.

Using Policies with Valint

Valint empowers users to consume policies as code from either public or private repositories, offering flexibility and customization options. To get started, simply install Valint and define your policies according to your compliance needs.

Installation: Begin by installing Valint using the provided script. Execute the following command in your terminal:

curl -sSfL https://get.scribesecurity.com/install.sh | sh -s — -t valint

Policy Definition: Next, define your policies according to your organization’s compliance requirements. Create a YAML file, such as my_policy.yaml, and structure it to encapsulate your desired rules. Here’s an example of what your policy file might look like:

name: my_image_policy
defaults:
  evidence:
    signed: true
rules:
  - uses: images/fresh-image@v1
    with:
       max_days: 100

  - uses: images/verify-labels-exist@v1
    level: warning
    with:
      labels: # image required to be labeled (Dockerfile LABEL command)
      - maintainer # Require a maintainer label.
      - org.opencontainers.image.source # Require images are labeled with there sources

In this example, we’ve defined a policy named my_image_policy, which mandates that evidence artifacts must be signed and that images must be created within the last 100 days. Additionally, it issues a warning if images lack specific labels.

Feel free to check out other rules we support out of the box.

Evidence Creation: Before evaluating your policies, you need to generate the necessary evidence. Use Valint to create evidence for your target image:

valint bom nginx:latest -o attest

This command generates evidence for the nginx:latest image, ensuring that it includes metadata such as image identity and creation time. By default, Valint utilizes the Sigstore service as the signer for evidence generation, which bind an OIDC identity to a certificate. However, Valint also supports the use of your own x509 PKI keys and CA chains for signing.

Sigstore Log In

Simply select the OIDC identifier of your choice to sign with.

Finally, you can review the success of the evidence generation process along with its identity to ensure its integrity and trustworthiness.

[2024-03-26 12:41:55]  INFO attest: [TRUSTED] sign success,
       CA: fulcio-signer,
       CN: sigstore-intermediate,
       Emails: [your_identity@gmail.com],
       URIs: []
...
[2024-03-26 12:41:55]  INFO attest: evidence generated successfully

Policy Evaluation: With your policy defined and evidence generated, it’s time to evaluate it against your supply chain components. Utilize the valint verify command followed by the target image and your policy file:

valint verify nginx:latest --policy my_policy.yaml

Evaluation Summary:

Once the evaluation completes, review the summary table provided by Valint logs.

Table

In this particular case, the Valint analysis illustrates that the nginx:latest image successfully meets the freshness requirement but lacks compliance with the labeling criteria, as anticipated. The provided table concisely outlines the evaluation status of each rule, noting whether evidence was properly signed.

SARIF-Formatted Results:

Furthermore, you can explore the SARIF-formatted results produced by Valint is a pushed as yet another peace of evidence to detail the evaluation, violations, levels and evidence refrences.

Supported Management Platforms:

This standardized format enjoys support from various security management systems such as GitHub, Azure, and Scribe SAAS. Scribe platforms not only handle policy results but also facilitate evidence management and offer extensive features for vulnerability management, metrics tracking, and more.

Information Preview:

To provide a glimpse of the information available in the policy results:

Screenshot

{
  "version": "2.1.0",
  "$schema": "https://raw.githubusercontent.com/oasis-tcs/sarif-spec/master/Schemata/sarif-schema-2.1.0.json",
  "runs": [
    {
      "tool": {
        "driver": {
          "informationUri": "https://scribesecurity.com",
          "name": "valint",
          "rules": [
            {
              "id": "fresh-image",
              "name": "Fresh Image",
             "shortDescription": {
                "text": "A rule to verify that the image is not older than a threshold"
             },
            },
            {
              "id": "labels",
              "name": "Labels",
             "shortDescription": {
                "text": "A rule to verify that the image has all the required labels"
             },
      },
      "results": [
       {
         "ruleId": "fresh-image",
         "ruleIndex": 0,
         "kind": "pass",
       },
       {
         "ruleId": "labels",
         "ruleIndex": 1,
         "kind": "fail",
         "level": "warning",
         "policy.violation": {
           "type": "Missing Labels",
           "details": [
            {
             "label": "not_found"
            },
            {
             "label": "org.opencontainers.image.source"
            }

       },

...
  ]
}

Policy Bundles

A bundle in Valint is a policy as code package, essentially a Git repository hosting a set of policies and rules. Users can set up their own bundle by forking the sample repository provided by Valint and customizing it according to their needs.

Fork and Customize: Start by forking Valint’s sample repository. Customize policies and rules to align with your organization’s needs.

Provision to Valint: Supply your custom bundle to Valint:

valint verify --bundle https://github.com/my_org/my_bundle.git \ 
               --policy my_policy.yaml

Custom rules

When customizing rules, the fundamental responsibility is to parse the evidence payload and report violations based on the defined compliance criteria. Whether you’re modifying existing rules or creating new ones.

Defining Compliance Criteria: Define the compliance criteria based on organizational policies, security standards, or regulations.

Defining the Evidence Criteria: Define the evidence expected to convey compliance.

Evaluating Compliance and Reporting Violations: Use the evidence payload to evaluate compliance against the defined criteria. Report violations if the component fails to meet the requirements.
Valint ensures that signature and evidence origin requirements are readily available for any custom rule.

While Valint currently employs OPA Rego for rule formulation, an exciting horizon awaits as Python rules are slated for integration in the near future.

What’s next?

Integration with Gatekeeper is now accessible! Refer to our documentation for details. Stay tuned for an upcoming blog post where we delve into this exciting development.

Keep an eye out for future blog posts where we’ll explore policy initiatives, including high-level policies that will implement security frameworks like SLSA and SSDF.

Exciting news for Python enthusiasts! Our latest update includes extensive Python support, providing a significant compatibility boost. This empowers policy writers to customize rules using Python and leverage its vast array of libraries.

Conclusion

In summary, Valint’s policy engine offers a robust solution for ensuring compliance within your supply chain. By leveraging its components such as evidence, policies, and bundles, organizations can streamline compliance efforts and mitigate risks effectively.

This content is brought to you by Scribe Security, a leading end-to-end software supply chain security solution provider – delivering state-of-the-art security to code artifacts and code development and delivery processes throughout the software supply chains. Learn more.