Macaron: Supply Chain Conformance Verifier and Policy Engine for SLSA

May 19, 2023 | 6 minute read
Behnaz Hassanshahi
Principal Researcher
Text Size 100%:

Today we are excited to announce Macaron: our new open source project from Oracle Labs. Macaron analyzes software artifact build pipelines to verify their conformance with supply chain security frameworks and prevent build integrity attacks. Software supply chain attacks are becoming more prevalent as the applications get more complex, particularly with the use of open source third-party code. Examples of build integrity attacks include stealing credentials, tampering with code, tampering with the code repository, and tampering with the build system. It is crucial that developers have guarantees that the third-party code they rely on is the code they expect. To address the challenges of software supply chain integrity, the community has developed Supply Chain Levels for Software Artifacts (SLSA), a maturity framework to improve artifact integrity.

Our tool, Macaron, determines which of the SLSA-defined properties are satisfied for a given artifact build system. Macaron also provides a policy engine to monitor the build integrity of dependencies used by a project.

How does Macaron work?

Macaron consists of two main components:

  1. An extensible and customizable checker platform that makes it easy to define checks to verify security properties.
  2. A policy engine that takes a policy as input and uses the results from the checks to determine whether an artifact is built as expected.

Macaron is based on a "Zero Trust Model" and utilizes non-falsifiable provenance documents generated by the build pipelines, if available, as input. Hence, to use Macaron effectively, project maintainers should use the existing tools provided by the SLSA community to generate such non-falsifiable provenance documents. However, Macaron can also operate in situations where some dependencies do not generate provenance documents.

Next, we show how Macaron can analyze an open source project that uses microservices and the Micronaut framework, and apply a policy to ensure that an artifact is built as expected (Macaron uses standard tools like CycloneDX plugins to identify dependencies).

Case study: Micronaut MuShop
Micronaut MuShop is a cloud-native microservices example for Oracle Cloud Infrastructure.

When we run Macaron on the Micronaut MuShop GitHub project, it automatically finds the project’s dependencies and runs checks for the top-level project and dependencies. For example, the build service check, as defined in SLSA, analyzes the CI configurations to determine if its artifacts are built using a build service. Another example is the check that determines whether a SLSA provenance document is available for an artifact. If so, it verifies whether the provenance document attests to the produced artifacts.

For the Micronaut MuShop project, Macaron identifies 48 dependencies that map to 24 unique repositories and generates an HTML report that summarizes the check results. The table below summarizes the check results for the project’s dependencies:

Check

Num deps pass

SLSA Level 3 Provenance is available

11

Provenance meets expectation

11

Version control system

24

Build Script

24

Build Service

20

Trusted builder Level 3

 

0

 


The results show that 11 dependencies out of 24 produce SLSA Level 3 provenance documents and meet expectations, and 20 dependencies meet the build service requirement. Currently the dependencies produced by Micronaut projects have a better security posture compared to other dependencies used by the Micronaut MuShop project because they produce non-falsifiable Level 3 provenance documents in their build pipelines. For example, the micronaut-core project produces a provenance document called multiple.intoto.jsonl that attests to the artifacts in the artifacts.zip file as part of its GitHub release. To read the content of the provenance document, use the following command:

cat multiple.intoto.jsonl | jq -r '.payload' | base64 --decode | jq

In principle, one can add a build expectation in the form of a Configure Unify Execute (CUE) policy to ensure that Micronaut artifacts are actually generated by the Micronaut repository's workflows and have not been tampered with by attackers. The provenance expectation check in Macaron uses expectation CUE files to verify if the expectations for Micronaut dependencies are satisfied. 

Macaron's policy engine accepts as input Datalog to specify the policy that needs to be satisfied. An example policy can verify if the Micronaut MuShop project and all its dependencies pass the build service check and the Micronaut provenance documents meet expectations. Thanks to Datalog’s expressive language model, it’s easy to add exception rules if certain dependencies do not meet a requirement. For example, the Mysql Connector/J dependency in the Micronaut MuShop project does not pass the build service check, but can be manually investigated and exempted if trusted. Overall, policies expressed in Datalog can be enforced by Macaron as part of your CI/CD pipeline to detect regressions or unexpected behavior.

Macaron is currently under active development. The documentation and instructions to run Macaron can be found in our GitHub repository. Please try the early prototype and let us know what you think. We look forward to feedback and contributions from the community.

Photo by Chelsea Audibert on Unsplash.

Behnaz Hassanshahi

Principal Researcher

Behnaz Hassanshahi is a Principal Researcher at Oracle Labs Australia. In her current role, Behnaz is leading project Macaron, a supply chain security analysis tool for open source projects. She is also working on static security analysis of Oracle Cloud Infrastructure.

In her previous project, Behnaz was the technical lead of Gelato, a Dynamic Application Security Testing (DAST) tool that analyses client-side JavaScript applications to find security vulnerabilities both at the client and server side of web applications. Gelato is now used as a product in Oracle. During the past few years, Behnaz has also explored various static and dynamic analysis as well as fuzzing techniques to analyse client-side and server-side JavaScript programs.

This is her second stint at Oracle Labs. When Behnaz worked here in 2015 as an intern in the Java Vulnerability Detection team, she designed an adaptive points-to framework that scales over OpenJDK.

After graduating from Amirkabir University of Technology (Tehran) in 2010 with a Bachelor of Science (Software Engineering), Behnaz did her PhD at the National University of Singapore. While at NUS, she was also awarded the Singapore International Graduate Award, and was a member of the Security Research Group.

Her thesis topic – Characterization, Detection and Exploitation of Injection Attacks in Android – and the security research prepared her well for her work at Oracle.

Behnaz conducts research in the area of  program analysis and its intersection with computer security that will improve the security of large complex software.

Education:

* PhD in Computer Science, 2011-2016, National University of Singapore

* BSc in Software Engineering, 2006–2010, Amirkabir University of Technology

Recent and upcoming events:

USENIX Security'23 (PC member)

SecDev'22 (Publicity Chair)

ISSTA'22 (PC member)

iMentor, CCS'21 (Panelist)

SCAM'21 - Engineering Track (Program Chair)

ACSAC'21 (PC member)

SCAM'20 (PC member)

ACSAC'20 (PC member)


Previous Post

Introducing Visual JavaScript Development

Shay Shmeltzer | 2 min read

Next Post


Announcing the General Availability of the SQL:2023 Standard

Gerald Venzl | 2 min read