[Proposal] Application Build Monitors and Attester

[nadgowdas]

Description:

Background:

Application builds (especially cloud-native microservice applications) today are operated as a "black-box". In a typical setting they are build using toolkits like docker build, kaniko or buidkit through CI pipelines (Jenkins or Tekton). The build process is input with source artifacts (e.g. *.go or *.py), dependency manifests (go.mod, requirements.txt) and a build recipe (Dockerfile). The process at the end then produces some build artifacts (e.g. container image or binary).

Around such a build process, security analytics are performed before build (through DevSecOps solutions by scanning source artifacts, e.g. Snyk) and after build (by scanning built images). Similarly, provenance collection is performed at the build task level (e.g. Tekton chains attesting the task that performed the build).

Proposal

There is an opportunity to have a build monitor and attester that could monitor the build process itself, collect the system trace, resource usage trace and create an attestation record for the same. For instance, consider a simple Dockerfile as follows:

FROM alpine:3.14
...
RUN curl -f -O https://hg.example.org/pkg-oss/archive/${EXAMPLE_VERSION}-${PKG_RELEASE}.tar.gz
...
RUN pip install -r requirements.txt

RUN COPY src/key.pub /etc/keys/my-key.pub
...

While we are running the build process for this application, we build system monitors (e.g. using eBPF) that would monitor the system activities (e.g. network access, file access, resource usage) and associate it with individual actions in the Dockerfile to create a signed build attestations.

{
   ...
   "build-steps":[{
          "cmd":" curl -f -O https://...",
          "records":[{
                   "network":{"egress": "192.128.0.4"},
                   "files": {"created": [""], "deleted", "modified":""},
                  "resources": {"time, "memory", "cpu"}
           }]
    }]
}

How this is useful/Impact

1. Identify any anomalous activity during the build (e.g. compare all egress connections against known "flagged" list)
2. It can complement SBOMs to provide more granular dependency requirements

Scope: How much effort will this take? ok to provide a range of options if or "not yet determined" for initial proposals. Feel free to include proposed tasks below or link a Google doc

1. It includes evaluation of existing tools (Witness, Jonah, Orion)
2. Coming up with a proposal for new requirements
3. Some prototype implementation and writeup

TO DO

• [ ] Security TAG Leadership Representative:
• [ ] Project leader(s):
• [ ] Project Members:
• [ ] Fill in addition TODO items here so the project team and community can see progress!
• [ ] Scope
• [ ] Deliverable(s)
• [ ] Project Schedule
• [ ] Slack Channel (as needed)
• [ ] Meeting Time & Day:
• [ ] Meeting Notes (link)
• [ ] Meeting Details (zoom or hangouts link)
• [ ] Retrospective

[lumjjb]

@nadgowdas to present to SSF to get feedback.

[lumjjb]

@nadgowdas any updates on this?

[nadgowdas]

yes, @lumjjb as presented in last time, in this project we were using eBPF to capture the build activity. So I briefly discussed with Liz Rice at the SecurityCon couple of weeks back and tried exploring their new project tetragon (https://github.com/cilium/tetragon). I had some good findings and would like to present in next meetup.

[stale[bot]]

This issue has been automatically marked as inactive because it has not had recent activity.

[anvega]

Hello @nadgowdas. Very cool stuff here. It looks like both presentations took place. Let us know if there are updated resources that should be linked to the issue, like the presentations or any progress on what was built and where folks can look for it.

[adityasaky]

I want to add that a bunch of us including @nadgowdas and @pxp928 worked on an in-toto predicate type to capture runtime traces: https://github.com/in-toto/attestation/blob/main/spec/predicates/runtime-trace.md

[stale[bot]]

This issue has been automatically marked as inactive because it has not had recent activity.