How to utilize the build profile  ## Metadata - Author: [[YouTube]] - Full Title: How to utilize the build profile - Category: #articles - Document Note: --- tags: [spdx, build-profile, supply-chain-security] author: SPDX Community source: YouTube reference: https://www.youtube.com/watch?v=5231_se-MBA date created: 2024-12-28 14:30 --- # 🏷️ Title: How to utilize the build profile ## 🧰 Action Inbox - [H1] Implement build profile in CI/CD systems — security and provenance tracking #devops - [H2] Document build processes for supply chain validation — vulnerability remediation #security - [H3] Integrate SPDX relationships for build introspection — nested build tracking #standards ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [SPDX 3.0 Specification](https://spdx.github.io/spdx-spec/v3.0/) - [SLSA Framework](https://slsa.dev/) ## 📝 Summary - SPDX build profile enables detailed documentation of software build processes for security and supply chain transparency - Addresses supply chain compromises, vulnerability remediation, build reproducibility, and quality auditing - Uses build elements and SPDX relationships to encode who, when, where, and why of builds - Supports hosted builds (GitHub Actions) and self-hosted environments with nested build capabilities - Still under development with serialization and relationship constraints being refined ## 📖 Main Content The SPDX build profile provides a standardized way to document software build processes, moving beyond just listing components to explaining how they were created. This addresses critical supply chain security needs as software goes through multiple transformation levels from source code to binaries to containers. The profile serves four main use cases: security (tracking supply chain compromises and vulnerabilities), reproducible builds (enabling independent verification), quality auditing (providing provenance for SBOM claims), and safety-critical applications (ensuring granular reasoning about software composition). Key technical concepts include build elements (representing build instances with IDs, timestamps, parameters, and configurations) and SPDX relationships that connect actors, source code, build tools, and outputs. The system supports both hosted environments like GitHub Actions and self-hosted build systems with nested build capabilities. ## 🗒️ Notes #### ⏱️ [00:00](https://www.youtube.com/watch?v=5231_se-MBA?t=0) — [H1] Build profile foundations - Key idea: Software development involves multiple transformation levels that need accurate documentation - Evidence: "Software being developed is to go through multiple levels of transformation so whether it's running source code to binaries taking binaries packaging them into a container" #### ⏱️ [00:45](https://www.youtube.com/watch?v=5231_se-MBA?t=45) — [H2] Security use case - Key idea: Build profile addresses supply chain compromises and vulnerability remediation - Evidence: "We're in the age where we also have supply chain compromises, build system gets compromised" #### ⏱️ [01:15](https://www.youtube.com/watch?v=5231_se-MBA?t=75) — [H2] Reproducible builds integration - Key idea: Multiple independent verifications strengthen build guarantees - Evidence: "If we are able to reproduce the build and multiple people can independently verify them against each other then we get that guarantees" #### ⏱️ [01:45](https://www.youtube.com/watch?v=5231_se-MBA?t=105) — [H2] Quality auditing capability - Key idea: Build information provides provenance assurance for SBOM component claims - Evidence: "How do I know that this contains compression library and in this case if we have the bill information propagated by provenance we can say that yeah this is how I figured out" #### ⏱️ [02:15](https://www.youtube.com/watch?v=5231_se-MBA?t=135) — [H2] Safety-critical applications - Key idea: Critical infrastructure requires granular software composition reasoning - Evidence: "Where we are dealing with human lives and critical infrastructure we need to be able to reason about what goes into the software" #### ⏱️ [02:45](https://www.youtube.com/watch?v=5231_se-MBA?t=165) — [H1] GitHub Actions example - Key idea: Hosted build systems can generate build profile information automatically - Evidence: "GitHub actions already generates all of this information and so when you are making a build profile you should be able to encode all of this information" #### ⏱️ [03:30](https://www.youtube.com/watch?v=5231_se-MBA?t=210) — [H2] Build element structure - Key idea: Build elements capture build ID, timing, parameters, configuration, and logs - Evidence: "Build ID start time end time the parameters that went into your build what configuration you use" #### ⏱️ [04:15](https://www.youtube.com/watch?v=5231_se-MBA?t=255) — [H2] SPDX relationships for build connections - Key idea: Relationships encode connections between actors, source code, build tools, and parameters - Evidence: "We use the spdx relationships so we've added a bunch of spdx relationships to the core model to encode those kind of relationships" #### ⏱️ [05:00](https://www.youtube.com/watch?v=5231_se-MBA?t=300) — [H2] Self-hosted build systems - Key idea: On-premise environments enable deeper build introspection with nested builds - Evidence: "Self-hosted environment or the on-prem environment that an organization may set up to do their bills" #### ⏱️ [05:45](https://www.youtube.com/watch?v=5231_se-MBA?t=345) — [H2] Nested build concept - Key idea: Complex builds can be decomposed into parallel sub-builds with parent-child relationships - Evidence: "Build that gets triggered by an event may spin up some parallel bills and so we introduce the concept called a nested build" #### ⏱️ [06:30](https://www.youtube.com/watch?v=5231_se-MBA?t=390) — [H2] Incremental implementation approach - Key idea: Build systems can incrementally add instrumentation capabilities over time - Evidence: "You can actually incrementally build this so it's a build system you know you can say okay I have this as a built at some point" #### ⏱️ [07:15](https://www.youtube.com/watch?v=5231_se-MBA?t=435) — [H2] Relationship-based extensibility - Key idea: Additional build information encoded as relationships allows gradual refinement - Evidence: "Once you get more information about what your bills your build looks like then you can add on to the existing s-bomb" #### ⏱️ [08:00](https://www.youtube.com/watch?v=5231_se-MBA?t=480) — [H2] Core build questions - Key idea: Build model addresses who, when, where, and why questions about builds - Evidence: "Built around the model around the who when where why type of questions of the build" #### ⏱️ [09:30](https://www.youtube.com/watch?v=5231_se-MBA?t=570) — [H3] Serialization challenges - Key idea: SPDX relationships representation in serialized format still being developed - Evidence: "Right now we're trying to figure out how to incorporate the relationships because that's where this profile shines" #### ⏱️ [11:00](https://www.youtube.com/watch?v=5231_se-MBA?t=660) — [H2] Scalable detail levels - Key idea: Build profile allows representing available information without mandating excessive detail - Evidence: "You represent what you need if you need to go down to the level and the detailed level for something like a safety use case you can but you don't need to" ## 📚 References - [SPDX 3.0 Specification](https://spdx.github.io/spdx-spec/v3.0/) - [SLSA Framework](https://slsa.dev/) - [Reproducible Builds Project](https://reproducible-builds.org/) - [OmniBOR](https://omnibor.io/) ## 🗣️ Paraphrase - SPDX build profiles document how software is built, not just what components it contains, addressing supply chain security through detailed build process tracking - The system uses build elements to capture build metadata and SPDX relationships to connect all the actors, tools, and inputs involved in the build process - Implementation can be incremental, starting with basic build information and adding more detailed nested build tracking as instrumentation capabilities improve ## 📰 Newsletter The SPDX community is developing build profiles that could revolutionize how we track software supply chains. Instead of just listing what's in your software, these profiles document exactly how it was built - from GitHub Actions workflows to complex multi-stage builds. This matters for WordPress developers because it provides concrete answers to security questions: Which exact tools built this plugin? What configuration was used? Can we reproduce this build independently? As supply chain attacks become more sophisticated, having this level of build transparency becomes essential for maintaining trust in the ecosystem. The profiles work incrementally - you can start simple and add more detail as your build systems evolve. Perfect for the diverse WordPress development landscape. Resources: [SPDX Specification](https://spdx.github.io/spdx-spec/), [SLSA Framework](https://slsa.dev/), [Reproducible Builds](https://reproducible-builds.org/) ## ✅ Action Items #### DevRel - Developer advocacy: Create build profile awareness sessions at WordCamps and meetups - Education: Develop workshops on supply chain security for WordPress developers - Developer experience: Integrate build profile concepts into WordPress development documentation - Developer marketing: Promote build transparency benefits in security-focused content - Community management: Facilitate discussions on WordPress supply chain security practices #### OSPO - Policy & Governance: Evaluate build profile requirements for organizational software policies - License Compliance: Assess how build profiles enhance license compliance verification - Security Management: Integrate build profiles into vulnerability response procedures - Software Inventory: Enhance SBOM strategy with build provenance tracking - Developer Support: Provide training on build profile implementation - Community Engagement: Participate in SPDX build profile standardization efforts - Strategic Alignment: Define KPIs for build transparency and supply chain security #### Community - Maintainers: Encourage WordPress core and plugin maintainers to adopt build profiles - Contributors: Create onboarding materials for build security best practices - Sponsors: Support development of WordPress-specific build profile tooling - Ecosystem: Coordinate with hosting providers on build profile integration #### WordPress - Core: Evaluate build profile integration for WordPress core releases - Core Performance: Include build profiles in performance measurement infrastructure - Core AI: Ensure AI-generated code includes appropriate build provenance - Plugins: Develop build profile guidance for plugin developers - Themes: Create build profile standards for theme distribution - Security: Integrate build profiles into security scanning and vulnerability assessment - Documentation: Create developer guides for implementing build profiles - Meta: Enhance .org infrastructure to support build profile metadata - CLI: Add WP-CLI commands for generating and validating build profiles - Hosting: Work with hosting providers on build profile support ## 🧪 Hypotheses - Build profiles will significantly improve vulnerability remediation speed by providing precise build context - Incremental build profile adoption will be more successful than requiring comprehensive implementation upfront - Integration with existing CI/CD systems like GitHub Actions will accelerate build profile adoption - Nested build tracking will reveal previously unknown supply chain dependencies and risks ### 📊 Methodology - Measure vulnerability response time before and after build profile implementation - Track build profile adoption rates across different implementation complexity levels - Survey CI/CD integration challenges and success factors - Analyze dependency discovery through nested build introspection ### ❓ Questions - How will build profiles handle proprietary or sensitive build environments while maintaining transparency? - What are the performance implications of comprehensive build tracking in large-scale development environments? - How can build profiles be standardized across different programming languages and ecosystems? ### 🔮 Future Research - Integration patterns between build profiles and container security scanning - Machine learning applications for anomaly detection in build processes - Cross-ecosystem build profile interoperability standards ### 💡 Implications - Practice: Development teams need new tooling and processes for build introspection and documentation - Policy: Organizations may require build profiles for security compliance and risk management - Security: Enhanced ability to trace and remediate supply chain compromises through detailed build provenance - Education: Developers need training on supply chain security concepts and build transparency practices - Funding: Investment needed in build profile tooling and integration with existing development infrastructure ### 🧠 Learning Styles Assessment Reading level estimate: 12th grade (technical conference presentation) #### 👀 Visual learners - Present: Build relationship diagrams, element connection visualizations - Improve: Interactive build graph explorers, visual diff tools for build changes #### 🔊 Aural learners - Present: Conference presentation format with speaker explanations - Improve: Podcast episodes on supply chain security, recorded Q&A sessions #### 🗣️ Verbal learners - Present: Clear definitions of technical terms, concrete examples - Improve: Storytelling around supply chain attack scenarios, analogies to physical manufacturing #### 🧩 Kinesthetic learners - Present: GitHub Actions examples, hands-on build system scenarios - Improve: Interactive labs, step-by-step build profile creation exercises #### 🧠 Logical learners - Present: Systematic breakdown of use cases, structured relationship models - Improve: Decision trees for build profile implementation, formal specification references #### 🧑‍🤝‍🧑 Social learners - Present: Q&A interactions, community discussion format - Improve: Working group participation guides, collaborative specification development #### 🧘‍♀️ Solitary learners - Present: Technical specification details, independent research references - Improve: Self-assessment checklists, individual implementation guides #### 🌿 Naturalistic learners - Present: Ecosystem-wide security implications, supply chain analogies - Improve: Environmental impact considerations, sustainable development practices ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear heading structure, technical term definitions - Improve: Enhanced alt text for diagrams, ARIA labels for complex visualizations #### Keyboard navigation - Present: Standard video controls, text transcript availability - Improve: Interactive diagram keyboard navigation, skip links for long technical sections #### Contrast and readability - Present: Standard video and text contrast - Improve: High contrast mode for technical diagrams, larger font options #### Text resizing and reflow - Present: Responsive text display - Improve: Diagram scaling at higher zoom levels, maintained readability #### Media and captions - Present: Video content available - Improve: Comprehensive captions, downloadable transcript, audio descriptions for diagrams #### Forms and interactions - Present: Basic Q&A interaction - Improve: Accessible form validation, clear error messaging for technical inputs ### 🌍 DEIB Assessment #### Cultural breadth - Present: International standards development context - Improve: Multi-region supply chain examples, localized security considerations #### Inclusive language - Present: Technical terminology with explanations - Improve: Plain language summaries, non-English technical term alternatives #### Neurodiversity support - Present: Structured presentation format, logical flow - Improve: Content chunking, consistent navigation patterns #### Representation - Present: Technical community participation - Improve: Diverse speaker representation, varied organizational perspectives #### Psychological safety - Present: Professional technical discussion - Improve: Clear community guidelines, constructive feedback frameworks ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Strong logical flow from supply chain risks to build profile solutions - Inductive strength: Good use of specific examples (GitHub Actions, self-hosted) to support general principles - Causal reasoning: Clear causal links between build documentation and security outcomes - - Document Tags: [[devops]] [[security]] [[standards]] - Summary: How to utilize the build profile - URL: https://www.youtube.com/watch?v=5231_se-MBA but I think a lot of this goes back to you know earlier on Kate was saying that you know we were on a basis more on facts and that's an opinion um and so like part of like software being developed is to go through multiple levels of transformation so whether it's running source code to um to to binaries taking binaries packaging them into a container into a virtual machine and so on you know there's a lot of things there's a lot of processes that go on in the creation of software and the more accurately we can represent these processes and document them uh the more factual information we have to then evaluate ecosystem and to kind of evaluate the claims that we have um so the build profile goes around couple use cases and the first is security uh you know we know about vulnerabilities um Rose and also talked a little bit about that but you know we we're in the age where we also have supply chain compromises you know build system gets compromised a built um tool and so spitting out bad bad output um in those cases we do also have to figure out when something like that happens how do we go about remediating it um I know I know we have folks from the reproducible bills here as well and that's also part of like ensuring uh a good build is one is like you know we can't understand uh the provenance of a build but at the same time you know if we are able to reproduce the build uh and multiple people can independently verify them against against each other then we get that guarantees as well and so a lot of this is also like um kind of borrowing and lending from a lot of the supply chain and build profit and side of things so we took a lot of inspiration from salsa we did a lot of inspiration for reproducible builds when we started creating this um also auditing the the quality and particular to build so this goes in a case where like uh initially when when we're giving an S1 we say here are the components of a particular piece of software now I'm saying that this contains um you know Carol's compression library but then the question is how do I know that this contains compression library and in this case if we have the bill information propagated by provenance we can say that yeah this is how I figured out the information and that kind of assurance and certainty of my theme then becomes stronger um and last but not least is and the area of safety you know where we are dealing with um human lives and like critical infrastructure we need to be able to reason about um what goes into the software and having that level of granularity is very important so I'm going to pass the initial talk about a few examples okay um so we have a couple of examples that we worked on uh one of them is the hosted build Paradigm so for example GitHub actions so if you were a software developer developing um like a python application uh you may be able to you know use a GitHub action to generate a wheel and publish it to pipe pipeline um I'll see if I can use the clicker um so if you if you think about the case of uh GitHub actions doing a build the instance of that build is what the build element is made of and that is the primary class that we're using in the build profile this information that's in the build element you should be able to generate that from um from the build stage that you're using so GitHub actions already generates all of this information and so when you are making a build profile you should be able to encode all of this information so this is things like the build ID start time end time the parameters that went into your build what configuration you use so typically for GitHub actions you would have a DOT GitHub and workflow for a build that happens on GitHub action so you can use that Ural over there um you can figure out what the what commit that build was done on and so you can encode that information in here and then you can also point to any log files that you find um now that's not enough for us to glean like what exactly happened in the build because things we want to know is like what um file was used to configure the build and we want to know like who configured the build and all of those connections we use uh the spdx relationships so we've added a bunch of spdx relationships to the core model to encode those kind of relationships between the actors in The build um what the source code is that went into the build and what parameters went into the build with the build tool so you have a number of things in here that Define for example all of the greens all of the pink stuff are all packages that are representing the build tool that was used to invoke the build uh the green one on the top is used to represent what the host was on which the build was invoked so it what VM you're using or what container you're using um you have like the teal ones which are the and the the orange one which is the build configuration so this is like any of the the yaml files or setup dot Pi that you would use to um Define what you're going to build and then there are some purple things over there which is using the curves identity uh and that is used to define like to identify uh who or what um triggered the build so the second example we try to use is something like a build system that you would host uh you would either host or you would install on your own machine and invoke the build so this is the it's it's almost like the self-hosted environment or the on-prem environment that an organ an organization May set up to do their bills so in this case um you would still be using a build element but there are also like more introspection that you can do uh so for example um the the build that gets triggered by an event May spin up some parallel bills and so we introduce the concept called a nested build um and so what you can do is if you wanted to introspect your builds a mode you could Define that okay if I do make for example that will trigger off um a compilation of source code or setup of build scripts or downloading of build scripts and each one of those can be a separate bill stage so in the nested example you'll have each one of those build stages as build elements and each of them will be able to encode like the the build element parameters so uh this is the top level build that you would Define and there will be a a nested build that happens that gets triggered after this and that's you can have a relationship called Bill child of uh that points to the bill that triggered of the secondary build yeah I think I think one of the things that I think maybe kept in mind when building this a lot of the discussion was around like how to implement this I think the idea is like if you look at GitHub actions if you look at things like Circle CI um Tech time Bill everything it's like kind of different levels of granularity and there's a little bit of mismatch between like sometimes of like what the build system can't instrument and what is required and so I think um like ethnicia went through the examples of this for what we're showing is that you can actually like incrementally build this so it's a build system you know you can say okay I have this as a built at some point I can say I have a few more nested bills but I don't know any information about that so I can be like no assertion uh and as the build system is able to happen the instrumentation they can then start building up the capabilities yeah and so this is why we uh encoded those um additional information as relationships because there are situations where you can introspect some of the bill but you can't introspect all of it unless you do more investigation and so once you get more information about what your bills your build looks like then you can add on to the existing s-bomb that you would create so uh this looks like the same thing right so this is just a this is a final site just to show like what you've seen but this is actually like just the elements of the build model um so I think the the main things to kind of show off is like just making a distinction I know we kind of picked this already into relationships there's a few few weeks out of date um but basically defining inputs outputs we built around the model around the like who when where where why type of questions of the build and So like um if you're creating a build system and that this is like the intention of um the the build profile is mainly for for Builders or build tools uh these are kind of things that you have to keep in mind right I think it's the questions of like um what goes into the inputs outputs the actors that you find in that and being able to then decompose this into nested builds examples like give a good overview on how that would be implemented I think that's that's all we have for the build profile okay I thank you do you have an example of how that's represented in an esport we don't have a serialized version of this yet actually right now we're trying to figure out how to incorporate the relationships because that's where this profile shines because you want those relationships so right now we have the relationships in the core model which we need to discuss how we can um you put some constraints around it meaning like if you're using the build profile then you have to use these uh mandatory relationships um but as far as serialization goes I don't we don't have an example of it right now but we're working on it no you hit that I I was more interested in the relationships and how those would be represented in a even a sample existing S1 which yeah so what it looks like so in spdx 3.0 relationship is a core element and so what you would do is just create an element that has the the from part which is represented by the IDS the from part the two part and then the relationship type and the relationship type is what all these are the build input of build child off so once you once you figure out okay that's that's what my build graph looks like you can create an s-bomb with a build profile in it so I I think just just to illustrate a little bit right this I think this thing um if you didn't have the build profile I think what you look like is you had an input which is like uh the build um basically the build input file and then you will have the package as output so in your tradition however you want to call it but like in a build materials today uh that just describes the content you would say like this package uh is uh using the generated um or this file generates this right and so what the build profile is is kind of like an overlay upon those elements to show you like okay this this is how the sausage is made this thank you one question these informations are barely useful for understanding it's a when we build some packages but recently these informations are getting more complex and complex so from my understanding spdx and s-bombs are for Securities and license complaints so so um my question is do you have any Vision or idea how detailed the information should be treated and created in the feeding in the S4 okay so the thing about spdx is you represent what you need if you need to go down to the level and the detailed level for something like a safety use case you can but you don't need to you only can you represent what you have available to you but if you want to go back and refine it further and put a lot more information about your builds there's a way to do it it's very scalable that's the whole idea here wait wait I think each profiles has a mandatory field so when we we'd like to use some certain profile we need to implement the mandatory field right right okay and in fact that's a great oh I can talk through the microphone that's a great lead-in for what we're going to talk about next which is the migration from spdx 2.3 to 3.0 and profiles and relationships both are our topics for that so um we've gotten last question here oh go ahead hi um I've read something about the omnibor that seems to be do a like a graph of everything that was done in the Builder does it connect to this do you plan on yeah so um in in we currently have the ability we currently have the ability to encode like get out which is what omnibar uses as hashes and the idea is that you know with that relationship with that within that you will be able to kind of overlay this information to kind of describe take that omnibal deck and then be able to translate it to like this was how I was built this is a composition of it and through those relationships and those hashes to be able to kind of directly map the inputs outputs more currently and so the the beauty of omnibor is that um all of the information comes out from the build system um a lot of the times when we are building a software we don't actually know what the interactions are like we don't we don't really see anything that statically compiled we just guess based on you know the the okay we gave this thing uh these kind of C Flags so I'm going to guess that that's what happened but we don't really know if it actually happens so it's more like yes you can use this to encode whatever information you know or you need to uh know or whatever you need to encode but with Omni omnibor it's it becomes more accurate right so my media is you cannot um like encode the whole omnibal reporter into a build profile yeah like that's the odd parts of it because we still have external references so you can encode the top part of it and point to an omnibal graph, How to utilize the build profile, YouTube, 01ka7p98dcq9gx9ab78bqsb6vx.