Presented at All Things Open 2025
Presented by Brett Smith - SAS Institute, Inc.
Title: Supply Chain Robots, Electric Sheep, and SLSA
Abstract: A talk about creating automation, shifting left, attack vectors, attestations, verification, zero-trust, and SLSA.
In the talk I cover creating automation...
Presented at All Things Open 2025
Presented by Brett Smith - SAS Institute, Inc.
Title: Supply Chain Robots, Electric Sheep, and SLSA
Abstract: A talk about creating automation, shifting left, attack vectors, attestations, verification, zero-trust, and SLSA.
In the talk I cover creating automation, shifting left, attack vectors, attestations, verification, zero-trust, and how the SLSA spec helps implement solutions for each. The main take away is that security needs to be applied everywhere in the pipeline. The talk should lead to a greater discussion around the challenges of securing the supply chain, supporting EO 14028 and ISO27001, and improving the security posture of your pipelines.
Attendee Takeaways
Answers for the following questions:
- Why do we need supply chain automation?
- What are common attack vectors in a supply chain?
- What techniques can we use to help secure the supply chain?
- What are the security benefits of supply chain automation and shift left?
- What specifications and tools can we use to help secure the supply chain?
Find more info about All Things Open:
On the web: https://www.allthingsopen.org/
Twitter: https://twitter.com/AllThingsOpen
LinkedIn: https://www.linkedin.com/company/all-things-open/
Instagram: https://www.instagram.com/allthingsopen/
Facebook: https://www.facebook.com/AllThingsOpen
Mastodon: https://mastodon.social/@allthingsopen
Threads: https://www.threads.net/@allthingsopen
Bluesky: https://bsky.app/profile/allthingsopen.bsky.social
YouTube: https://www.youtube.com/@allthingsopen
2025 conference: https://2025.allthingsopen.org/
Size: 4.2 MB
Language: en
Added: Oct 20, 2025
Slides: 26 pages
Slide Content
Platform Engineering:
Herding the Electric Sheep
Brett Smith
<[email protected]>
20250020
Platform Engineering
Internal Developer
Platform
DevOps
Also DevOps
Platform Engineering
Internal Developer Platform
IDP
How does it benefit the developers?
IDP
How does it benefit the security team?
IDP
How does it benefit the platform team?
IDP
How does it benefit the enterprise?
Shift Left - Automate Right
SBOM
Software Bill of Materials
SLSA
Source Track Build Track
Track/Level Requirements Focus
Build L0 (none) (n/a)
Build L1 Provenance
showing how
the package
was built
Mistakes,
documentation
Build L2 Signed
provenance,
generated by a
hosted build
platform
Tampering after
the build
Build L3 Hardened build
platform
Tampering during
the build
Track/Level Requirements Focus
Source L1 Use a version
control system
First steps towards
operational
maturity
Source L2 History and
controls for
protected
branches & tags
Preserve history
and ensure the
process has been
followed
Source L3 Signed
provenance
Tampering by the
source control
system
Source L4 Code review Tampering by
project
contributors
Policy as Code (PaC)
Security is codified, automated, open, and accessible to all stakeholders
Key Features:
●Codification
●Automation
●Integration
●Consistency
Benefits:
●Improved Security
●Enhanced Compliance
●Increased Efficiency
●Reduced Errors
●Greater Agility
●Improved Collaboration
Shift-Down Security
Shift-Down Security
The Platform
Services
The Platform
●Agentic AI
●MCP Servers
●RAGs
What is next?
Pipeline visibility: "What's the status of my
deployment unit?"
Policy compliance: "Has it run all required
checks to ship?"
Security validation: "Did security scans run and
what were results?"
Test verification: "Are all tests complete and
passing?"
Promotion readiness: "Can we move to the next
stage?"
Where to start?
●Assess existing tools and services across teams
●Identify patterns and consolidation opportunities
●Visualize findings for a clear landscape overview
●Design platform around main use cases first
●Address uncommon scenarios later
●Use core solutions to drive broader adoption
●Collaborate on unique needs for potential platform improvements
●Prioritize the main 80% - 10% - 10%, and handle exceptions
Potential Pitfalls
●Outliers
●Exceptions
●Team Exceptions
●Vendor Lock in: Avoid dependency on a single vendor or specialized tech
●Cloud-agnostic strategies enable flexibility and easier upgrades
●One Offs: Emphasize industry standards over custom solutions
Ask yourself:
●How many electric sheep do you
produce?
●How many developers do you
have?
●How many teams?
Do you have:
●A complex software development
process?
●A lot of different tools and
services to integrate?
●Extensive compliance and
security requirements?
Is Platform Engineering Right for You?
AMA
I am Smitty and I am afraid of robots
Brett Smith
GitHub <https://github.com/xbcsmith>