# DORA but for security

You may have heard of [DORA metrics](https://dora.dev/) but have you ever thought about it in context of security? In this post, we're going to share our thoughts on how we think we should measure security of a product.

Metrics
* Time taken to find out a component is potentially vulnerable: It's important to find out if a software component is vulnerable before the attackers do. We've used the word "potential" here as it may turn out that:
* You're not impacted by the vulnerability
* You cannot investigate it on your own as you're relying on an upstream vendor to confirm

For instance, if we scan the software artifact every one hour- this implies that the value of this metric is one hour.

Tip: we recommend scanning SBOMs to be more efficient with vulnerability scanning of artifacts. Its faster and more economical to parse structured formatted(usually JSON) file than an entire filesystem.

* Time taken to update status of vulnerability: Consumers of software would appreciate knowing the status of a vulnerability, similiar to how we treat outages. This is where [VEX documents](https://www.ntia.gov/files/ntia/publications/vex_one-page_summary.pdf) play a huge role as we could automate the response to customers about it and be more transparent.

* Time to patch: As the time taken to exploit known vulnerabilities is getting slimmer by the minute, we need a way to automate patching when possible. Note: the process of patching isn't just bumping up the dependency version, it is also the amount of time taken to verify the change hasn't impacted the service in any other way, verified via a testing suite in continuous delivery pipeline.

Tip: automated patching can get noisy pretty fast, it is important to have a patching process that involves very little involvement from humans so the patch pull/merge requests aren't stuck in a queue.

In the next post, we'll look at how we can apply this to container artifacts.

# Supply chain for containers

Containers have become the de-facto standard over the last decade on how we run applications. In this post, we'll look at how an end-to-end secure delivery pipeline might look like for containers.

NOTE: we're skipping a couple important steps here when we say end-to-end. For instance, signing git commits, securing build systems, etc are crucial but we're focusing on the container artifact itself here.

* Build system: We need the build system to attach SBOM and SLSA provenance to the OCI artifact it produces.

Tip: We recommend using buildkit as it can do [both for us](https://github.com/moby/buildkit/tree/master/docs/attestations).

Internals tutorial: If you're curious about how attestations are attached to the OCI artifact, you can try
* Get the manifest of the image:
``crane manifest <imagename>:<tag>``
* In the manifests array, you should see one of them having an annotation that says "vnd.docker.reference.type": "attestation-manifest".
* You can try a crane manifest on that hash and a subsequent crane blob to get the SBOM and provenance.

* Signature: At this point, we should sign and push the artifact to the registry. Note: this does not mean the artifact is ready to be deployed, we've just confirmed that our build pipeline has produced an artifact we can trust.

Tip: we recommend using cosign's keyless way to do this.

Internals tutorial: If you're curious how this has modified your OCI artifact, you can check your signature has been uploaded by:

crane manifest ttl.sh/image:sha256-<digest>.sig | jq .

* Vulnerability scanning: Scan the SBOM attached in the OCI artifact. If there are any vulnerabilities found, the pipleine should fail based on the threat model your organisation has defined. Scanning should also be triggered at a regular interval to discover vulnerabilities over time.

Product opportunity: user inputs their threat model, compliance levels, etc via dashboards and we provide some way for user to manage it.

* VEX document: Its important to triage each vulnerability and generate a VEX document that can be embedded into OCI artifact. If you're wondering, "Wow, I can't go through a 100 vulnerabilties", you're absolutely justified to feel so. Automated patching, static analysis, minimal images can come a long way to reduce this burden.

TIP: it is important to sign the VEX document to prove it has come from you.

Product opportunity to reduce triage burden:
* Triaging vulnerabilties can be a long process potentially involving multiple organisations or open source projects.
* Automated patching and generation of VEX
* Static analysis to declare "not impacted",etc to generate VEX.

* Policy enforcement: Now that we've everything needed to verify who,when,how an artifact was produced, its time to verify the information in an automated fashion before deployment takes place.

Product opportunity: An integration point with Kubewarden to make policy management and authoring seamless: https://github.com/kubewarden/kubewarden-controller/issues/527

There's no silver bullet to solve this problem but following this process can come a long way to reduce attack surface for your software.