Add a recommendation for the `builder.id` URI to resolve to
documentation that explains the scope, level, and accuracy of the
builder.

Signed-off-by: Mark Lodato <lodato@google.com>

Previously we used "builder" and "build platform" interchangably, but
this was never stated explicitly anywhere, leading to confusion for
several readers. Also we never defined "control plane", and the diagram
used "platform" inconsistently.

Changes:

-   Update diagram to add "Build Platform (builder)" to the diagram,
    showing a box over the pieces that are trusted, and rename the old
    "Platform" to "Control Plane". This is now consistent with the model
    in Verifying Build Systems.
-   In the text, prefer "build platform" over "builder" unless it is
    very clear that the latter is short for the former. Now the only
    places that "builder" is used are:
    -   As a field name (`builder`)
    -   In the "Builder" section of the doc, where it is explained that
        the two terms mean the same thing.
    -   In the Verification section, where "builder" is unambiguous.

Signed-off-by: Mark Lodato <lodato@google.com>

There is often confusion whether a "build platform" is just the software
that is running, or if it is a specific instance of that software
including all of the people involved running it. The intention is the
latter, so say that specifically.

Signed-off-by: Mark Lodato <lodato@google.com>

Signed-off-by: Mark Lodato <lodato@google.com>

I meant to remove this in slsa-framework#664 but messed up the merge in 6605135.

Signed-off-by: Mark Lodato <lodato@google.com>

In order to help reduce confusion around ephemeral and isolated
properties, these have been merged into a single isolated property.
Additional clarity is added to the isolated build requirement, relating
it to the previous hermetic requirement.

Relates to slsa-framework#657

Some content taken from a comment in slsa-framework#685: slsa-framework#685 (comment)

Signed-off-by: arewm <arewm@users.noreply.github.com>

Most readers probably don't want to be taken to the latest approved
version, but they might want to select a release candidate (or even know
that a release candidate exists). So refer them to the version selector
rather than adding a link.

Also display what version it is a draft of, to make it more clear to
readers.

Signed-off-by: Mark Lodato <lodato@google.com>

* Update supply chain threat model and diagrams.
- Move threat C to the Source Track.
- Swap threats D and E. Now the division is ABC == Source, D == Dependencies, EFGH == Build.

Signed-off-by: kpk47 <kkris@google.com>

* fix threats-overview

Signed-off-by: kpk47 <kkris@google.com>

* revert changes to old files

Signed-off-by: kpk47 <kkris@google.com>

* Add files via upload

Signed-off-by: kpk47 <1079282+kpk47@users.noreply.github.com>

* version supply chain threats diagrams

Signed-off-by: kpk47 <kkris@google.com>

* update references to supply-chain-chreats*.svg in v1.0 spec

Signed-off-by: kpk47 <kkris@google.com>

* Add files via upload

Signed-off-by: kpk47 <1079282+kpk47@users.noreply.github.com>

* Add files via upload

Signed-off-by: kpk47 <1079282+kpk47@users.noreply.github.com>

* delete supply-chain-threats--editable.svg

Signed-off-by: kpk47 <kkris@google.com>

* delete supply-chain-threats-no-labels.svg

Signed-off-by: kpk47 <kkris@google.com>

---------

Signed-off-by: kpk47 <kkris@google.com>
Signed-off-by: kpk47 <1079282+kpk47@users.noreply.github.com>

Signed-off-by: Mark Lodato <lodato@google.com>

This is no longer used now that we read the next/prev from the nav YAML.

Signed-off-by: Mark Lodato <lodato@google.com>

Signed-off-by: kpk47 <kkris@google.com>