Perhaps we should consider extending the SLSA flowchart to the left towards the step of design and decisions on this steps that leads to insecure situations (regardless of implementation in code) that have been done deliberately by an actor in order to gain an advantageous edge on attacking the system.

Seen on a revised take on the current SLSA flowchart below, on the left side -

Design can be affected by either an internal or external actors that either have direct or indirect affect on the design decision, realizing a decision might gain an actor a privilege by definition or by particular power/knowledge the actor has.

Actions such as standardization to meet common denominator, regulations (through lobbying perhaps), and crowdsourced decisions can be prone to this method of supply chain attack.

Some examples of this might include:

• SSL Export certificates (which also lead to the FREAK vulnerability) - the export regulations were mandated by the US when dealing with SSL certificate schemes, the influence of such a regulation resulted in insecure design decision directly affecting SSL servers. The reasoning behind it was that gov actors would be able to decrypt the traffic, which, back then, was not something that was thought of as possible by the industry.
• On a similar note - multiple cases in the past that involved designing a ‘master key’ for decryption by design. Some of those decisions were heavy with debate for enabling this feature.

Note of clarification - OWASP TOP-10 2021 added insecure design as category A04 - it is not to be confused with this notion as it deals with the developer/business decision making process more than a malicious intent.