How does Notary and TUF can deter a solarwinds equivalent future attack?

[nathanawmk]

This is a honest, sincere and genuine question.

I like to genuinely understand how does Notary and TUF can deter a solarwinds equivalent future attack? As no one caught the compromised code as it was signed with a code signing certificate by SolarWinds themselves and sent straight to their clients as part of the routine update process.

I am looking to possible solutions that stop compromised code in its track before getting to the packaging, signing stage which Notary, TUF does?

Thank you!

SOURCE: https://owasp.org/www-chapter-singapore/assets/presos/Deconstructing_the_Solarwinds_Supply_Chain_Attack_and_Deterring_it_Honing_in_on_the_Golden_SAML_Attack_Technique.pdf,

[mlieberman85]

Have you taken a look at: https://github.com/cncf/tag-security/blob/main/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf

That explains some of it. There are also different tools for different stages of the system development lifecycle. I'm personally not convince Notary/TUF itself can secure against these kinds of attacks directly.

If the information that has come out about the Solarwinds attack is correct, then you would need to secure your continuous integration and build tools. Notary and TUF helps out though because ideally your CI and build tools would run through the same supply chain process as everything else, maybe even a bootstrapped one. So if someone were to compromise your CI or build tools you could detect that those CI and build tools weren't adequately signed.

[JustinCappos]

This really isn't in scope for TUF and Notary. They protect validly built and signed software.

The in-toto project (https://in-toto.io) is geared toward this. It's now being used by the Solarwinds folks and a lot of other groups.

On Mon, Aug 30, 2021 at 10:52 PM Michael Lieberman @.***> wrote:

Have you taken a look at: https://github.com/cncf/tag-security/blob/main/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf

That explains some of it. There are also different tools for different stages of the system development lifecycle. I'm personally not convince Notary/TUF itself can secure against these kinds of attacks directly.

If the information that has come out about the Solarwinds attack is correct, then you would need to secure your continuous integration and build tools. Notary and TUF helps out though because ideally your CI and build tools would run through the same supply chain process as everything else, maybe even a bootstrapped one. So if someone were to compromise your CI or build tools you could detect that those CI and build tools weren't adequately signed.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/cncf/tag-security/issues/768#issuecomment-908409535, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGROD4GX3FZ653WK7JKOKDT7OLL7ANCNFSM5DBBJAJA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[mlieberman85]

Be careful. As it stands now in-toto helps in establishing provenance, but doesn't work to secure the build tools themselves. e.g. if you are compiling with gcc and someone replaced has hijacked your gcc, in-toto as it stands today will sign that without additional tooling.

[TheFoxAtWork]

@nathanawmk has your question be adequately addressed?

[stale[bot]]

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