mitigation-20-Build Toolchain Hardening

[carmithersh]

Hi, please review this mitigation for build toolchain hardening, related to risk 11: Build Toolchain and Service Supply Chain Compromise

[aaronsearle]

This is a really interesting topic. Though I wondering if it is a bit open ended, I am struggling to figure out what I would do to evidence compliance to the controls..and if I can't evidence it then it is arguably not a control I would be able to stand behind. Lets discuss at the next session, maybe there will be other opinion or perhaps we can figure out a way to break down.

[carmithersh]

Adding this information for the discussion https://cheatsheetseries.owasp.org/cheatsheets/Software_Supply_Chain_Security_Cheat_Sheet.html#build-threats Carmit Hershman*|* Senior Software Architect, CTO Office *|* JFrog Mobile: +972.52.4349692 *|* jfrog.com <http://www.jfrog.com/>

…

On Mon, Jun 15, 2026 at 11:19 PM aaronsearle ***@***.***> wrote: ***@***.**** commented on this pull request. This is a really interesting topic. Though I wondering if it is a bit open ended, I am struggling to figure out what I would do to evidence compliance to the controls..and if I can't evidence it then it is arguably not a control I would be able to stand behind. Lets discuss at the next session, maybe there will be other opinion or perhaps we can figure out a way to break down. — Reply to this email directly, view it on GitHub <#75?email_source=notifications&email_token=ASYTKNQGT7KO7TLTPNEQ3K35ABK6BA5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTINJQGA4DINJZGAZ2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#pullrequestreview-4500845903>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ASYTKNTUWSTUXPCKU2DKNJL5ABK6BAVCNFSNUABGKJSXA33TNF2G64TZHMYTANBVG4ZDSMBRGU5US43TOVSTWNBWGU4TCOJSG43TPILWAI> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/ASYTKNX3XCVBHEG5SR7O7HD5ABK6BA5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTINJQGA4DINJZGAZ2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android <https://github.com/notifications/mobile/android/ASYTKNTU7GSSOE7MSSX77T35ABK6BA5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTINJQGA4DINJZGAZ2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

[aaronsearle]

I think for this to work it might have to be adapted to include a governance step that determines and evidences what appropriate level of hardening should be determined. This is one way of handling open ended lists. The list itself is all fine, decent practical stuff but it is open ended and a list of recommendations.
How I've seen this handled before is that the control ends up with two parts two it, one to handle determining and evidencing a decision is made by the organisation on what is appropriate to them at that point in time and their rationale for it. Then the second part is demonstrating they adhere to that.
However; some of the list I would just call out and have concrete controls around them themselves (e.g code signing and scanning the binary artefacts should already be existing controls)

Adding this information for the discussion https://cheatsheetseries.owasp.org/cheatsheets/Software_Supply_Chain_Security_Cheat_Sheet.html#build-threats Carmit Hershman*|* Senior Software Architect, CTO Office | JFrog Mobile: +972.52.4349692 | jfrog.com http://www.jfrog.com/
…
On Mon, Jun 15, 2026 at 11:19 PM aaronsearle @.> wrote: @.* commented on this pull request. This is a really interesting topic. Though I wondering if it is a bit open ended, I am struggling to figure out what I would do to evidence compliance to the controls..and if I can't evidence it then it is arguably not a control I would be able to stand behind. Lets discuss at the next session, maybe there will be other opinion or perhaps we can figure out a way to break down. — Reply to this email directly, view it on GitHub <#75?email_source=notifications&email_token=ASYTKNQGT7KO7TLTPNEQ3K35ABK6BA5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTINJQGA4DINJZGAZ2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#pullrequestreview-4500845903>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASYTKNTUWSTUXPCKU2DKNJL5ABK6BAVCNFSNUABGKJSXA33TNF2G64TZHMYTANBVG4ZDSMBRGU5US43TOVSTWNBWGU4TCOJSG43TPILWAI . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS https://github.com/notifications/mobile/ios/ASYTKNX3XCVBHEG5SR7O7HD5ABK6BA5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTINJQGA4DINJZGAZ2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG and Android https://github.com/notifications/mobile/android/ASYTKNTU7GSSOE7MSSX77T35ABK6BA5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTINJQGA4DINJZGAZ2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA. Download it today! You are receiving this because you authored the thread.Message ID: @.***>

[joshbressers]

Could it be worth referring to https://slsa.dev/ here instead of trying to create a set of controls?

[carmithersh]

@joshbressers referencing SLSA build track does make sense. Would it be instead of adding the content, or in addition?
regarding evidencing it, as slsa suggests:

• you add the artifact provenance to indicate which code repo and build tool you used
• you maintain a list of approved and hardened build and code tools that you trust (w/out their levels)
• you block use of any artifact that was not produced through your approved hardened tools

so the evidence are:

• slsa build provenance
• your trusted list of build toolchain

then the mitigation is: check that slsa provenance exists, extract the build tools from the slsa evidence and check they are your trusted tools

[meekrosoft]

Addin to Josh's comment, here is how slsa define it: https://slsa.dev/spec/v1.2/assessing-build-platforms#build-platform-components

[carmithersh]

Hi team. please review the updated requirements based on research on NIST SSDF requirements, pointing on IEC 62443-4-1 SM-7 - development environment security.
I rather not just link to SLSA, as it only handles build system, while regulations and frameworks also handle the rest of the SDLC toolchain.
also, there seems to be a clear guildline as to how to meet regulatory requirements for toolchain hardening but it is not a single evidence; but more of a full process that produces an evidence bundle that auditors evaluate, so I have added this into the requirements.

[jorok]

As discussed during the meeting - overall I agree with the nature of the mitigation. I am worried it is very broad and a lot of parts to it. Would it be better to break it down into several controls?

[carmithersh]

@aaronsearle, can you please add your feedback? do you think this mitigation should be broken down into:

• Access Controls
• Environmental Isolation and Integrity
• Integrity Verification
• Monitoring and Logging
• Maintenance and Assurance

Or, should it be kept as one mitigation for different aspects of how to harden the build toolchain and provide provenance for the process