Reformat using markdownlint and set up GH Action.

Also set up dependabot to keep the GitHub Action up-to-date.

Author: MarkLodato

.github/dependabot.yml

@@ -0,0 +1,6 @@
+version: 2
+updates:
+- package-ecosystem: github-actions
+  directory: "/"
+  schedule:
+    interval: daily

.github/workflows/lint.yml

@@ -0,0 +1,11 @@
+name: Lint
+on: [pull_request]
+jobs:
+  lint:
+    runs-on: ubuntu-latest
+    steps:
+    - name: Markdown Lint
+      uses: nosborn/github-action-markdown-cli@6e34c67b8bd3406dd8ee6eeba353ca4c66793501 # v2.0.0
+      with:
+        files: .
+        config_file: ".markdownlint.yaml"

.markdownlint.yaml

@@ -0,0 +1,43 @@
+# MD004/ul-style - Unordered list style
+MD004:
+  style: "dash"
+
+# MD007/ul-indent - Unordered list indentation
+MD007:
+  indent: 4
+
+# MD013/line-length - Line length
+MD013: false
+
+# MD029/ol-prefix - Ordered list item prefix
+MD029:
+  # List style
+  style: "ordered"
+
+# MD030/list-marker-space - Spaces after list markers
+MD030:
+  # Spaces for single-line unordered list items
+  ul_single: 3
+  # Spaces for single-line ordered list items
+  ol_single: 2
+  # Spaces for multi-line unordered list items
+  ul_multi: 3
+  # Spaces for multi-line ordered list items
+  ol_multi: 2
+
+# MD033/no-inline-html - Inline HTML
+MD033: false
+
+# MD034/no-bare-urls - Bare URL used
+MD034: false
+
+# MD046/code-block-style - Code block style
+MD046:
+  style: "fenced"
+
+# MD047/single-trailing-newline - Files should end with a single newline character
+MD047: true
+
+# MD048/code-fence-style - Code fence style
+MD048:
+  style: "backtick"

README.md

@@ -42,11 +42,11 @@ software developers and consumers.
 
 SLSA addresses three issues:
 
--  Software producers want to secure their supply chains but don't know
+-   Software producers want to secure their supply chains but don't know
    exactly how;
--  Software consumers want to understand and limit their exposure to supply
+-   Software consumers want to understand and limit their exposure to supply
    chain attacks but have no means of doing so;
--  Artifact signatures alone prevent only a subset of the attacks we care about.
+-   Artifact signatures alone prevent only a subset of the attacks we care about.
 
 ### Supply Chain Threats
 
@@ -225,7 +225,7 @@ dependencies' supply chains plus its own sources and builds.
 
 Special cases:
 
-*   A ZIP file is containing source code is a package, not a source, because it
+-   A ZIP file is containing source code is a package, not a source, because it
     is built from some other source, such as a git commit.
 
 ### SLSA Levels
@@ -297,6 +297,7 @@ Common - [Security]                  |        |        |        | ✓
 Common - [Access]                    |        |        |        | ✓
 Common - [Superusers]                |        |        |        | ✓
 
+<!-- markdownlint-disable-next-line MD036 -->
 _○ = required unless there is a justification_
 
 [Access]: requirements.md#access
@@ -366,15 +367,15 @@ satisfy all of the SLSA build requirements.
 That said, verified reproducible builds are not a complete solution to supply
 chain integrity, nor are they practical in all cases:
 
-*   Reproducible builds do not address source, dependency, or distribution
+-   Reproducible builds do not address source, dependency, or distribution
     threats.
-*   Reproducers must truly be independent, lest they all be susceptible to the
+-   Reproducers must truly be independent, lest they all be susceptible to the
     same attack. For example, if all rebuilders run the same pipeline software,
     and that software has a vulnerability that can be triggered by sending a
     build request, then an attacker can compromise all rebuilders, violating the
     assumption above.
-*   Some builds cannot easily be made reproducible, as noted above.
-*   Closed-source reproducible builds require the code owner to either grant
+-   Some builds cannot easily be made reproducible, as noted above.
+-   Closed-source reproducible builds require the code owner to either grant
     source access to multiple independent rebuilders, which is unacceptable in
     many cases, or develop multiple, independent in-house rebuilders, which is
     likely prohibitively expensive.
@@ -396,38 +397,38 @@ data models. Currently this is joint work between
 [Binary Authorization](https://cloud.google.com/binary-authorization) and
 [in-toto](https://in-toto.io/) but we invite wider participation.
 
-*   [Standard attestation format](https://github.com/in-toto/attestation#in-toto-attestations)
+-   [Standard attestation format](https://github.com/in-toto/attestation#in-toto-attestations)
     to express provenance and other attributes. This will allow sources and
     builders to express properties in a standard way that can be consumed by
     anyone. Also includes reference implementations for generating these
     attestations.
-*   Policy data model and reference implementation.
+-   Policy data model and reference implementation.
 
 For a broader view of the software supply chain problem:
 
-*   [Know, Prevent, Fix: A framework for shifting the discussion around
+-   [Know, Prevent, Fix: A framework for shifting the discussion around
     vulnerabilities in open
     source](https://security.googleblog.com/2021/02/know-prevent-fix-framework-for-shifting.html)
-*   [Threats, Risks, and Mitigations in the Open Source Ecosystem]
+-   [Threats, Risks, and Mitigations in the Open Source Ecosystem]
 
 Prior iterations of the ideas presented here:
 
-*   [Building Secure and Reliable Systems, Chapter 14: Deploying Code](https://sre.google/static/pdf/building_secure_and_reliable_systems.pdf#page=339)
-*   [Binary Authorization for Borg] - This is how Google implements the SLSA
+-   [Building Secure and Reliable Systems, Chapter 14: Deploying Code](https://sre.google/static/pdf/building_secure_and_reliable_systems.pdf#page=339)
+-   [Binary Authorization for Borg] - This is how Google implements the SLSA
     idea internally.
 
 Other related work:
 
-*   [CII Best Practices Badge](https://bestpractices.coreinfrastructure.org/en)
-*   [Security Scorecards](https://github.com/ossf/scorecard) - Perhaps SLSA
+-   [CII Best Practices Badge](https://bestpractices.coreinfrastructure.org/en)
+-   [Security Scorecards](https://github.com/ossf/scorecard) - Perhaps SLSA
     could be implemented as an aggregation of scorecard entries, for at least
     the checks that can be automated.
-*   [Trustmarks](https://trustmark.gtri.gatech.edu/)
+-   [Trustmarks](https://trustmark.gtri.gatech.edu/)
 
 Other takes on provenance and CI/CD:
 
-*   [The Path to Code Provenance](https://medium.com/uber-security-privacy/code-provenance-application-security-77ebfa4b6bc5)
-*   [How to Build a Compromise-Resilient CI/CD](https://www.youtube.com/watch?v=9hCiHr1f0zM)
+-   [The Path to Code Provenance](https://medium.com/uber-security-privacy/code-provenance-application-security-77ebfa4b6bc5)
+-   [How to Build a Compromise-Resilient CI/CD](https://www.youtube.com/watch?v=9hCiHr1f0zM)
 
 <!-- Links -->
 

controls/README.md

@@ -7,23 +7,23 @@ NOTE: This is still a work in progress.
 
 ## Contents
 
-*   [Software Attestations](attestations.md): How to represent software artifact
+-   [Software Attestations](attestations.md): How to represent software artifact
     metadata.
-*   [Policies](policy.md): Conventions for how to express security policies
+-   [Policies](policy.md): Conventions for how to express security policies
     based on attestations.
-*   [Survey](survey.md): Survey of existing and in-development controls that
+-   [Survey](survey.md): Survey of existing and in-development controls that
     relate to the framework.
 
 ## Project Goals
 
 (1) Build an ecosystem around software attestations and policies, applicable to
 use cases beyond SLSA and supply chain integrity:
 
-*   Establish clear and consistent terminology and data models.
-*   Define simple interfaces between layers/components, to allow
+-   Establish clear and consistent terminology and data models.
+-   Define simple interfaces between layers/components, to allow
     compatibility between implementations and to encourage discrete,
     composable technologies.
-*   Recommend a cohesive suite of formats, conventions, and tools that are
+-   Recommend a cohesive suite of formats, conventions, and tools that are
     known to work well together.
 
 Currently, there are various projects in this space with overlapping missions
@@ -34,8 +34,8 @@ desire.
 
 (2) Provide recipes for achieving SLSA, built on the ecosystem above:
 
-*   Identify base technologies that meet the SLSA requirements, which serves as
+-   Identify base technologies that meet the SLSA requirements, which serves as
     guidance to system implementers on how to build SLSA-compl8iant services.
     Example: "CI/CD systems should produce provenance attestations in format X."
-*   Recommend simple end-to-end solutions for end users (software developers) to
+-   Recommend simple end-to-end solutions for end users (software developers) to
     achieve SLSA. Example: "Configure GitHub this way to reach SLSA 3."

controls/attestations.md

@@ -21,14 +21,14 @@ in the trusted computing world.)
 An attestation is the generalization of raw artifact/code signing, where the
 signature is directly over the artifact or a hash of artifact:
 
-*   With raw signing, a signature *implies* a single bit of metadata about the
+-   With raw signing, a signature *implies* a single bit of metadata about the
     artifact, based on the public key. The exact meaning must be negotiated
     between signer and verifier, and a new keyset must be provisioned for each
     bit of information. For example, a signature might denote who produced an
     artifact, or it might denote fitness for some purpose, or something else
     entirely.
 
-*   With an attestation, the metadata is *explicit* and the signature only
+-   With an attestation, the metadata is *explicit* and the signature only
     denotes who created the attestation. A single keyset can express an
     arbitrary amount of information, including things that are not possible with
     raw signing. For example, an attestation might state exactly how an artifact
@@ -101,17 +101,17 @@ recognize that other choices may be necessary in various cases.
 
 Summary: Generate [in-toto](https://in-toto.io) attestations.
 
-*   Envelope: **[DSSE](https://github.com/secure-systems-lab/dsse/)** (TODO:
+-   Envelope: **[DSSE](https://github.com/secure-systems-lab/dsse/)** (TODO:
     Recommend Crypto/PKI)
-*   Statement:
+-   Statement:
     **[in-toto/attestation](https://github.com/in-toto/attestation/)**
-*   Predicate: Choose as appropriate.
-    *   [Provenance](https://github.com/in-toto/attestation/tree/main/spec/provenance.md)
-    *   [SPDX](https://github.com/in-toto/attestation/tree/main/spec/spdx.md)
-    *   If none are a good fit, invent a new one.
-*   Bundle and Storage/Lookup:
-    *   Local Filesystem: TODO
-    *   Docker/OCI Registry:
+-   Predicate: Choose as appropriate.
+    -   [Provenance](https://github.com/in-toto/attestation/tree/main/spec/provenance.md)
+    -   [SPDX](https://github.com/in-toto/attestation/tree/main/spec/spdx.md)
+    -   If none are a good fit, invent a new one.
+-   Bundle and Storage/Lookup:
+    -   Local Filesystem: TODO
+    -   Docker/OCI Registry:
         **[sigstore/cosign](https://github.com/sigstore/cosign)**
 
 See [survey](survey.md) for other options.

controls/survey.md

@@ -48,21 +48,21 @@ Raw signing            | ✓        | ✓         | ✗         |         |
 
 Legend:
 
-*   ✓ Defines this layer
-*   ✗ Does not support this layer
-*   ~ Imposes requirements on this layer
-*   (blank) No opinion on this layer
+-   ✓ Defines this layer
+-   ✗ Does not support this layer
+-   ~ Imposes requirements on this layer
+-   (blank) No opinion on this layer
 
 Columns:
 
-*   Envelope: Defines the envelope layer of the attestation.
-*   Statement: Defines the statement layer of the attestation.
-*   Predicate: Defines the predicate layer of the attestation.
-*   Storage: Provides a mechanism for attestation storage and retrieval.
-*   Generation: Provides a mechanism for generating attestations.
-*   Policy: Provides a mechanism for consuming attestations and rendering policy
+-   Envelope: Defines the envelope layer of the attestation.
+-   Statement: Defines the statement layer of the attestation.
+-   Predicate: Defines the predicate layer of the attestation.
+-   Storage: Provides a mechanism for attestation storage and retrieval.
+-   Generation: Provides a mechanism for generating attestations.
+-   Policy: Provides a mechanism for consuming attestations and rendering policy
     decisions.
-*   Status: Is it available now?
+-   Status: Is it available now?
 
 ## Envelope Layer (not specific to Attestations)