Lucas Gonze – Securing InnerSource #InnerSourceSummit2025

Lucas Gonze – Securing InnerSource #InnerSourceSummit2025 🔗 **Source:** [Lucas Gonze – Securing InnerSource #InnerSourceSummit2025](https://www.youtube.com/watch?v=0Nw9UUpkKzQ) > [!note]+ Document Notes > tags: [innersource, security, open-source-security, enterprise-security] > author: Lucas Gonze > source: InnerSource Commons > reference: https://www.youtube.com/watch?v=0Nw9UUpkKzQ > date created: 2024-12-19 10:30 > > # 🏷️ Title: Securing InnerSource - Balancing Openness and Security >  ## 🧰 Action Inbox - [H1] Inventory inner source security threats specific to your organization — 05:23 #security - [H2] Implement manual security scorecard assessment for inner source projects — 14:30 #assessment - [H3] Establish vulnerability tracking for internal dependencies — 12:15 #compliance ## 🧭 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 - [OpenSSF](https://openssf.org/) - [SLSA Framework](https://slsa.dev/) - [Security Scorecard](https://github.com/ossf/scorecard) ## 📝 Summary - Lucas Gonze presents a framework for securing InnerSource projects, identifying unique security threats that differ from open source - Key focus on adapting open source security tools like SLSA and Security Scorecard for internal enterprise contexts - Emphasizes being precise about threats rather than vague handwaving about security concerns - Provides practical manual assessment approach when automated tools don't fit inner source environments - Bottom line: Inner source needs tailored security approaches that account for reduced scrutiny and different threat models ## 📖 Main Content InnerSource projects face unique security challenges that fall between traditional open source and proprietary software models. Unlike open source projects with vast community scrutiny, inner source has smaller review pools but broader internal access than typical proprietary code. The presentation identifies several specific threat categories: lack of external scrutiny, presumed safety of internal components, overly broad access controls, weaker security culture, maintainer turnover, and tooling gaps. These threats require different mitigation strategies than pure open source or closed source approaches. Open source security tools like SLSA (Supply-chain Levels for Software Artifacts) and OpenSSF's Security Scorecard provide valuable frameworks but need cultural translation for inner source contexts. For example, vulnerability tracking must connect to enterprise security infrastructure rather than just public CVE databases. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/0Nw9UUpkKzQ?t=0) — [H1] Introduction: Is InnerSource Too Open or Too Closed? - Key idea: InnerSource security sits between open and proprietary models - Evidence: "Is it too open to be secure or too closed, too proprietary, or just right?" #### ⏱️ [01:30](https://youtu.be/0Nw9UUpkKzQ?t=90) — [H2] Speaker Background and Approach - Key idea: Fractional OSPO consultant with extensive open source experience - Evidence: "I work for a variety of corporate clients doing supply chain security compliance work" #### ⏱️ [02:45](https://youtu.be/0Nw9UUpkKzQ?t=165) — [H1] Threat Identification Framework - Key idea: Security requires precise threat identification, not vague concerns - Evidence: "When it comes to security you want to avoid handwaving. You want to be as precise as you can be" #### ⏱️ [03:30](https://youtu.be/0Nw9UUpkKzQ?t=210) — [H2] Limited Prior Art on InnerSource Security - Key idea: Very little existing research on inner source specific security threats - Evidence: "I went out and I looked for prior art on inner source security threats and I hardly found anything" #### ⏱️ [04:15](https://youtu.be/0Nw9UUpkKzQ?t=255) — [H1] Threat 1: Reduced Community Scrutiny - Key idea: Smaller review pool means vulnerabilities persist longer - Evidence: "Heartbleed took tens hundreds of millions of people using that code to eventually get the eyeballs to identify" #### ⏱️ [05:23](https://youtu.be/0Nw9UUpkKzQ?t=323) — [H1] Threat 2: Presumed Safety of Internal Components - Key idea: Enterprise context creates false assumption that internal code is vetted - Evidence: "You assume that everybody else involved is being vetted by the organization" #### ⏱️ [06:45](https://youtu.be/0Nw9UUpkKzQ?t=405) — [H2] Malicious Insiders and Infected Components - Key idea: Internal threats include both bad actors and compromised systems - Evidence: "There can be malicious insiders and infected components inside your firewall" #### ⏱️ [07:30](https://youtu.be/0Nw9UUpkKzQ?t=450) — [H1] Threat 3: Overly Broad Access Controls - Key idea: Internal access controls often less precise than open source equivalents - Evidence: "Write and commit access controls may be too broad... privileges are very fine grained in open source" #### ⏱️ [08:45](https://youtu.be/0Nw9UUpkKzQ?t=525) — [H2] Security Culture Challenges - Key idea: Organizational pressure can override security best practices - Evidence: "The CEO calls you up and says I want you to email me the SSH key" #### ⏱️ [09:30](https://youtu.be/0Nw9UUpkKzQ?t=570) — [H2] Maintainer Knowledge Loss - Key idea: Corporate turnover can eliminate security expertise from projects - Evidence: "The expertise in a project that it takes to vet PRs may potentially lead to security problems can leave the company" #### ⏱️ [10:15](https://youtu.be/0Nw9UUpkKzQ?t=615) — [H1] SLSA Framework Overview - Key idea: SLSA secures build and distribution pipeline through cryptographic signing - Evidence: "Only accept libraries, binaries into your build that have been signed in a cryptographically secure way" #### ⏱️ [11:00](https://youtu.be/0Nw9UUpkKzQ?t=660) — [H2] OpenCVE and Internal Vulnerability Tracking Gap - Key idea: Public vulnerability databases don't cover internal security issues - Evidence: "It's essential but it's also not quite right in an inner source context because obviously your internal vulnerabilities can't be there" #### ⏱️ [12:15](https://youtu.be/0Nw9UUpkKzQ?t=735) — [H1] Security Scorecard Tool Analysis - Key idea: OpenSSF Scorecard provides quick security assessment metrics - Evidence: "Quickly assess open-source projects for risky practices" #### ⏱️ [13:45](https://youtu.be/0Nw9UUpkKzQ?t=825) — [H2] Cultural Translation Required for InnerSource - Key idea: About half of security scorecard metrics need adaptation for internal use - Evidence: "About half of them you can leave intact... some of these need cultural translation" #### ⏱️ [14:30](https://youtu.be/0Nw9UUpkKzQ?t=870) — [H1] Manual Implementation Strategy - Key idea: Don't modify code, use manual assessment with same conceptual framework - Evidence: "Don't touch the code. Keep the algorithm, keep the concept but do it this way" #### ⏱️ [15:45](https://youtu.be/0Nw9UUpkKzQ?t=945) — [H2] Extended Metrics for InnerSource - Key idea: Add specific categories for inner source threats to existing frameworks - Evidence: "I extended the metrics... to cover the inner source issues" ## 📚 References - [OpenSSF Security Scorecard](https://github.com/ossf/scorecard) - [SLSA Framework](https://slsa.dev/) - [OpenSSF Project Portfolio](https://openssf.org/) - [OpenCVE Database](https://opencve.org/) ## 🗣️ Paraphrase - InnerSource security exists in a unique space between open source transparency and proprietary protection, requiring specialized threat assessment - Existing open source security tools provide valuable frameworks but need cultural adaptation for enterprise internal contexts - Manual assessment approaches can be more practical than automated tools when dealing with inner source specific security requirements ## 📰 Newsletter **Securing Your InnerSource Projects: Beyond Open Source Tools** Lucas Gonze's recent InnerSource Summit presentation highlights a critical gap in enterprise security: InnerSource projects face unique threats that traditional open source security tools don't fully address. **Key Insight**: While tools like SLSA and Security Scorecard provide excellent frameworks, they need "cultural translation" for internal enterprise contexts. For example, vulnerability tracking must connect to your enterprise security infrastructure, not just public CVE databases. **Practical Application**: Consider implementing a manual security scorecard assessment for your InnerSource projects. Focus on threats like reduced community scrutiny, overly broad internal access controls, and maintainer knowledge loss through corporate turnover. **Action Step**: Start by inventorying security threats specific to your InnerSource context - be precise rather than vague about what you're protecting against. Resources: [OpenSSF](https://openssf.org/), [SLSA Framework](https://slsa.dev/), [Security Scorecard](https://github.com/ossf/scorecard) ## ✅ Action Items #### OSPO - Security Management: Develop inner source specific threat assessment methodology, vulnerability tracking integration with enterprise security tools - Software Inventory: Extend SBOM strategy to include internal component provenance and signing - Policy & Governance: Create inner source security guidelines that balance openness with enterprise security requirements #### Community - Maintainers: Establish succession planning and security expertise transfer protocols for inner source projects - Contributors: Implement security-focused code review training specific to inner source contexts #### FAIR - Technical independence: Ensure inner source security tools and processes don't create vendor lock-in - Governance artifacts: Document security assessment methodologies and threat models ## 🧪 Hypotheses - Inner source projects have fundamentally different security threat profiles than pure open source or proprietary projects - Manual security assessment can be more effective than automated tools for inner source contexts - Cultural translation of open source security tools provides better coverage than building from scratch - Reduced community scrutiny in inner source environments increases vulnerability persistence time ### 📊 Methodology - Comparative analysis of security scorecard metrics across open source, inner source, and proprietary contexts - Threat modeling workshops focused on enterprise-specific inner source scenarios - Manual assessment pilot programs using adapted security scorecard frameworks ### ❓ Questions - How can organizations quantify the security impact of reduced community scrutiny in inner source projects? - What metrics best capture the unique threat profile of enterprise inner source environments? - How should vulnerability disclosure policies adapt for inner source projects that span multiple business units? ### 🔮 Future Research - Comprehensive taxonomy of inner source specific security threats across different industry contexts - Automated tooling development for inner source security assessment - Integration patterns between enterprise security infrastructure and open source security frameworks ### 💡 Implications - Practice: Security teams need specialized approaches for inner source that go beyond traditional open source or proprietary models - Policy: Enterprise security policies must account for the hybrid nature of inner source development - Security: Inner source security requires cultural translation rather than wholesale adoption of open source tools - Education: Security training programs need inner source specific modules addressing unique threat scenarios ### 🧠 Learning Styles Assessment Reading level estimate: 12th Grade (Flesch-Kincaid Grade Level) #### 👀 Visual learners - Present: Threat categorization lists, tool comparison matrices, scorecard examples - Improve: Security threat flow diagrams, visual comparison of open source vs inner source threat models #### 🔊 Aural learners - Present: Conference presentation format with speaker explanation - Improve: Audio summary of key threat categories and mitigation strategies #### 🗣️ Verbal learners - Present: Clear definitions of security concepts, concrete examples like Heartbleed - Improve: Glossary of security terms, analogies comparing security models #### 🧩 Kinesthetic learners - Present: Manual scorecard assessment process, practical implementation steps - Improve: Hands-on security assessment workshops, threat modeling exercises #### 🧠 Logical learners - Present: Systematic threat categorization, step-by-step adaptation methodology - Improve: Decision trees for tool selection, quantitative risk assessment frameworks #### 🧑‍🤝‍🧑 Social learners - Present: Conference presentation encouraging audience participation - Improve: Collaborative threat modeling sessions, peer security review processes #### 🧘‍♀️ Solitary learners - Present: Self-directed assessment frameworks, individual analysis methods - Improve: Self-assessment checklists, independent study materials on security frameworks #### 🌿 Naturalistic learners - Present: Ecosystem thinking about security dependencies and supply chains - Improve: Analogies to natural systems, sustainability considerations for security practices ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear heading structure, descriptive list formatting - Improve: Alt text for any security diagrams, ARIA labels for interactive elements #### Keyboard navigation - Present: Standard presentation format with logical flow - Improve: Keyboard accessible interactive assessment tools #### Contrast and readability - Present: Standard text presentation with good contrast - Improve: High contrast mode for security assessment interfaces #### Media and captions - Present: Video presentation available with transcript - Improve: Closed captions for technical terminology, audio descriptions ### 🌍 DEIB Assessment #### Cultural breadth - Present: Enterprise security context applicable globally - Improve: Examples from different organizational cultures and regulatory environments #### Inclusive language - Present: Technical language with clear definitions - Improve: Plain language summaries, avoid security jargon without explanation #### Neurodiversity support - Present: Well-structured content with clear categorization - Improve: Visual organization aids, consistent formatting patterns #### Representation - Present: Focus on technical content rather than personal examples - Improve: Diverse case studies from different organizational contexts ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Clear logical progression from threat identification to mitigation strategies - Inductive strength: Pattern recognition from open source security to inner source adaptation - Causal reasoning: Links between organizational factors and security vulnerabilities - Analogical strength: Effective comparison between open source and inner source security models #### Fallacies - Appeal to authority: Reliance on OpenSSF tools without full justification for inner source contexts - False dichotomy: Presentation of security as "too open" vs "too closed" oversimplifies the spectrum #### Tone of voice - Overall tone: Practical and expert-driven with appropriate technical depth for security practitioners ### 🛡️ DARVO Analysis - Deny: No instances of denial or minimization of security concerns - Attack: No attacks on security practices or practitioners - Reverse victim/offender: No victim/offender role reversals identified - Emotional cues and rhetoric: Balanced, technical presentation focused on practical solutions ## 🎯 Conclusion InnerSource security requires a specialized approach that adapts open source security frameworks for enterprise contexts. The key insight is "cultural translation" - keeping proven algorithms and concepts while modifying implementation for internal threat models. Organizations should start with precise threat identification, then systematically adapt existing tools rather than building from scratch. The manual assessment approach provides a practical starting point for most organizations to improve their inner source security posture. ## 🧱 Refactor Appendix ### 📚 Literature Split Pad Purpose: Stage CEE units that become Literature notes. Split level: H --- ## Full Transcript [00:05] All right, we're going to talk about [00:06] securing inner source. And the question [00:09] we're going to ask is, is it too open to [00:12] be secure or too closed, too [00:15] proprietary, [00:17] or just right? And how can you make it [00:20] just right? And really, that question of [00:22] how can you make it just right is the [00:25] one we're going to be talking about. [00:26] This is an active talk. It's about [00:28] providing you with tools. [00:30] So, [00:32] my name is Lucas Gans. You can find me [00:34] on GitHub. It's probably the best place [00:36] to look me up. Um, I um have been an [00:39] open source contributor since the [00:40] beginning of my career, and that's how I [00:42] make a living. Like, I've just been [00:44] involved in so many projects, kind of [00:46] seen everything. Uh, and I am a uh [00:49] fractional uh open-source program [00:52] office. I work for a variety of [00:54] corporate clients um doing uh you know [00:57] supply chain security compliance work, [00:59] ESPO work um and uh community [01:03] development and sometimes marketing for [01:04] their open source projects. [01:10] We're going to talk about threats. [01:13] We're going to talk about tooling for [01:15] open-source uh security. We're going to [01:18] talk about the applicability of that [01:20] tooling to inner source projects. We're [01:24] going to talk about how to adapt things [01:26] that are slightly maladapted to [01:28] specifics about an inner source. And [01:30] then we're going to do a Q&A. But the [01:32] Q&A is going to be a little different [01:33] because I'm going to ask you the [01:35] questions. [01:37] >> That's right. [01:40] Um so first of all let's talk about [01:42] threats because um when it comes to um [01:46] security you want to avoid handwaving. [01:48] You want to be as precise as you can be [01:51] because there are a lot of vague threats [01:52] that may be impossible. Um and and there [01:56] may be threats that seem tiny that are [01:58] very real. [02:00] Um, so, uh, to give an example of a [02:04] threat that is specific to o to to inner [02:07] source security and actually I'm going [02:09] to backtrack a little bit here. When I [02:11] started working on this slide, I went [02:12] out and I looked for prior art on inner [02:15] source security threats and I hardly [02:18] found anything. I mean, I found one [02:20] thing and it was very, you know, loosey [02:23] goosey. Um, and so I've been working on [02:27] this list for about a month now and it's [02:30] probably just the beginning. So here we [02:31] go. First of all, there's no external [02:34] community scrutiny of um inner source [02:38] code and the inner source community is [02:41] smaller than the open- source community, [02:43] right? You think about something like [02:45] heartbleleed like it took you vast [02:48] numbers of people you tens hundreds of [02:51] millions of people using that code to [02:53] eventually get the eyeballs to identify [02:56] the source of that code and in the in an [02:58] inner source context that is not the [03:01] case. Number two, in a in any enterprise [03:06] context, in any business context, you [03:08] assume that everybody else involved is [03:12] being um they're vetted by the [03:15] organization, right? If they do [03:17] something that's that's kind of wrong, [03:20] they're going to lose their job. Um but [03:23] uh that leads to the presumption that [03:26] upstream components things that um [03:29] you're using that are coming from other [03:31] parts of your organization are safe and [03:34] that is not necessarily true. This is [03:36] where we get back to that 8020 rule. [03:38] There can be malicious insiders number [03:41] one. Uh, and number two, there can be [03:43] infected components inside your firewall [03:47] um that are looking to ride on something [03:50] they can get into to get into something [03:53] downstream from there. [03:55] Number three, um, write and commit [03:58] access controls may be too broad. So you [04:02] think about or even read access. Think [04:04] about something like uh um Google's [04:06] famous mono repo. Like the the scale of [04:10] access there is really remarkable and in [04:13] an open-source context uh uh um [04:17] privileges are very fine grained. We're [04:20] super aware of what anybody out there in [04:24] the world can do to your repository and [04:27] we're very precise about what we allow. [04:29] That is often not the case inside the [04:32] firewall. I don't want to encourage [04:35] locking things down, although that's [04:37] kind of what security people do a lot, [04:39] but more I want you to think about the [04:41] precise things that you do have to give [04:43] away. There may be a way for somebody to [04:45] leverage something you think should be [04:47] open into the privilege to look at [04:50] environment settings in your CI and then [04:53] use those environment settings to you [04:55] escalate into something like writing to [04:58] your main AWS account, right? So little [05:01] leaks can uh can cause can come much [05:04] bear. Um [05:07] there's the issue of security culture. [05:10] Um cautiousness around security. Um is [05:13] something that has to be absorbed [05:14] organizationally. So the classic one is [05:16] the CEO calls you up and says I want you [05:19] to email me the SSH key. [05:22] And it's really hard to say no to that. [05:24] There's there's really no good answer to [05:27] that. Um, and that's much harder inside [05:30] uh an inner source project than it is in [05:32] an open source project. Um, number six, [05:36] this list goes on and on. I could stop [05:38] at any time because you you know like [05:41] this the list of possible threats is so [05:43] long, but it is worth being as precise [05:45] as possible. And that is the single [05:47] biggest message I want you to take away. [05:51] Be precise about uh threats to your [05:53] inner source projects and exhaustive as [05:55] much as you can. Um, next maintainers [05:59] may have left the company in an [06:00] open-source project. People stay on [06:03] projects for years. Uh, they may stay on [06:06] them their whole lives. There's a thing [06:08] I built in 2020 that I still get emails [06:11] about and I'll I'll just do it as long [06:13] as I can. um and the expertise in a [06:16] project that it takes to vet PRs that [06:20] may potentially lead to um security [06:23] problems uh can leave the company. So, [06:27] watch out for projects that seem to have [06:29] nobody with the expertise to vet PRs. Uh [06:34] and the last one that I'm going to [06:35] mention, but not the last one by any [06:37] means, is a tooling gap. And that's what [06:39] I'm going to focus on here because I [06:42] don't have that much time and I want to [06:44] get as deep as I can to to help you have [06:48] the tools to use in the future. [06:53] Okay, we're going to talk about some [06:55] specific tools that are um oriented [06:58] towards opensource security. One [07:02] specific tool that's really critical is [07:04] Salsa. SLSA, [07:07] security levels. Somebody want to finish [07:10] this for me? Okay. Salsa is used to um [07:14] to to um secure the build and [07:18] distribution process. For example, um [07:21] you might um only accept libraries, [07:25] binaries into your build that have been [07:27] signed in a cryptographically secure [07:29] way. And um that protects you from doing [07:34] a build with an infected library. Um [07:37] which is a great way to get an exploit [07:40] into your into your application. Um [07:43] Salsa is is a is a terrific tool that is [07:47] very useful. There are things about it [07:49] that are kind of p, you know, particular [07:51] to open source, but it goes to the [07:54] question of your build and distribution [07:57] pipeline. Um, next, um, as an example, [08:02] um, actually I'm going to jump through [08:04] here because I think I talked for a [08:06] little too long about the earlier things [08:07] and I'm going to need more time, but I [08:09] want to bring up openc.org, [08:13] which is the master repository of uh, [08:17] publicly reported vulnerabilities. And [08:20] it's really important that that is wide [08:22] open to the to the world and um and [08:26] anybody can read it and check and check [08:28] for themselves whether there is a [08:30] vulnerability in something they're [08:32] using. Um and it is essential but it's [08:36] also not quite right in an inner source [08:39] context because obviously your internal [08:42] vulnerabilities can't be there. So it it [08:46] does certain essential jobs and in an [08:51] inner source context you have to find a [08:53] way to stand in for it. [08:56] Um open SSF is the main organization [09:01] that um that hosts um tools for the [09:05] health uh the security of the open [09:07] source ecosystem as a whole. So if you [09:10] think about a typical node.js JS [09:13] project, you do a single uh npm ad that [09:17] can lead to 50 or 500 uh dependencies [09:20] getting pulled into your project. You [09:22] can't possibly vet all of those. Open [09:25] SSF exists to you know create a context [09:30] where we can hope to have reasonable [09:33] security across such an enormous web of [09:36] dependencies. This is uh these are just [09:38] a a few examples of the things there. Uh [09:43] I'm not going to go too deep into this, [09:45] but be aware that when you're looking [09:48] for um tools that address the [09:50] open-source side of your world, go here, [09:53] study it, get to know the options. Um [09:57] even if their project isn't fully [09:59] mature, it's addressing an important [10:01] problem that um you probably should have [10:04] somebody on your team who is aware of. [10:08] I'm going to talk about a particular [10:10] project now. Um, and I'm choosing this [10:14] one just because uh I want to go into [10:17] detail, but be aware that the same [10:19] issues will affect almost anything you [10:22] use. Scorecard is a project I'm going to [10:24] talk about. This is a open SSF project. [10:28] It was originally called Scorecards. [10:31] And what scorecard does is, well, let's [10:34] take a look at the website. [10:36] Um it is uh okay let's let's just look [10:40] at this tagline quickly assess [10:42] open-source projects for risky [10:45] practices. Number one quickly the speed [10:48] of assessment is part of its value. [10:50] Number two assess these are metrics for [10:54] security quality. I mean keep in mind [10:56] they're quick metrics right and a real [10:59] security audit takes real time. Um but [11:01] quick metrics have their own value. Um [11:05] and for risky practices, right? So with [11:09] in a broad brush kind of way, we can [11:11] identify risky practices. And the truth [11:13] is broad brushes do actually matter. [11:16] There are a lot of kind of you know e [11:18] there's a lot of lowhanging uh fruit in [11:20] this space. And notice uh in this list [11:23] here the numbers that there's, you know, [11:25] these are numbers zero out of 10, eight [11:27] out of 10. Um and if you actually look [11:29] in they're even finer grained. [11:33] All right. [11:38] Yeah. Yeah. Okay. Here we go. So, what [11:40] does scorecard measure? Um, [11:44] it has, um, you know, it checks whether [11:47] you're using dependabot to look for [11:50] known CVEes in any of your upstream [11:53] dependencies. Here you are. you have 500 [11:56] npm dependencies in your project from [11:59] the one little thing that you pulled in [12:01] deliberately and you need to keep track [12:03] of every reported CVE and every [12:06] available patch and then whether it's [12:09] applicable to your software. So um [12:14] there's a there's a lot of detail to [12:16] track there. Um and dependabot does that [12:19] well. The problem with dependabot it is [12:22] for opensource software and and publicly [12:25] reported cdees. So take this lesson [12:29] away. You want to do something like that [12:32] for your inner source software. You want [12:35] to be checking for known [12:37] vulnerabilities. And you know, with [12:41] internal development, your apps team, [12:44] they're going to have a list of these [12:46] things they're going to know, but they [12:47] can't shut down everything as soon as [12:49] something is found. And making a fix can [12:51] take a long time. It can be hard. You're [12:54] going to have a count of open [12:55] vulnerabilities, and you need to know [12:57] what it is. So for each one of these [13:02] there's a comparable kind of lesson to [13:05] learn that um it's a thing that matters [13:10] and it may be harder or easier in an [13:12] inner source context. So I looked at [13:15] each one of these and I asked um how [13:20] well the uh open-source oriented version [13:24] would be would adapt to an inner source [13:26] context. What I found is there's one [13:28] that you just want to drop. It doesn't [13:30] make any difference. Um, and about half [13:32] of them you can leave intact. So like [13:35] this one, binary artifacts. Don't check [13:38] binaries of libraries into your into [13:41] your repo, right? Because that's where, [13:45] you know, that's where the exploits [13:46] live. It's a perfect place to poison [13:48] your build. Um, and and no change like [13:52] that. the open source, you know, logic [13:55] is directly applicable, but some of [13:56] these need uh uh cultural translation [13:59] and I'm going to talk about that now [14:03] for the ones that need cultural [14:05] translation. What does that mean and how [14:07] do you go about the process of doing it? [14:10] Oops. Um so the one I'm going to talk [14:13] about is the vulnerability count. Um, so [14:18] and just as an example of one that has a [14:20] really clear porting kind of process. [14:23] Um, so the way that you get the [14:25] vulnerability count in an open source [14:27] project is you check for CVEEs in all [14:32] your known upstream dependencies. Just [14:34] it's a straight count from opencve.org. [14:38] Um, and those aren't all known for a [14:41] proprietary project. a lot of them are [14:43] in your your corporate your enterprise [14:46] level security infrastructure. Um so a [14:49] cultural translation of this metric [14:52] would have to include connecting to [14:55] whatever enterprise level software [14:57] you're using for tracking [14:59] vulnerabilities. So be aware that the [15:02] original thing is useful and there's [15:04] very likely open source software on [15:06] almost anything that anybody builds. Um [15:09] but internally uh in an inner source [15:12] context very importantly the more reuse [15:15] you have the more impact a vulnerability [15:18] has. Um so there is a downside to all [15:22] this great superhealthy reuse which is [15:25] greater impact of vulnerabilities in [15:28] reused components. [15:31] Um what does it mean to implement one of [15:34] these projects? Um, [15:37] first of all, um, think about your [15:40] threats. [15:41] Number two, um, like be precise with [15:44] your threats. Um, be specific, avoid [15:47] needless fear, but be concrete. Number [15:50] two, look for tools that can address [15:52] those. Number three, look for the gaps, [15:55] the things that can happen in your [15:57] context, in an inner source context that [16:00] wouldn't happen in an open source [16:01] context. And fortunately almost every [16:04] tool for open source um security is open [16:07] source and you can adapt it. Pretty much [16:10] everything from open SSF is very clean [16:12] and maintainable. I've touched those [16:14] things. It's super easy. Um [16:18] so the key thing for you to remember is [16:21] um well okay so I'm going to talk about [16:24] porting uh security scorecard itself [16:26] right now. And here is my advice to you. [16:28] Don't touch the code. Keep the [16:30] algorithm. keep the concept um but do it [16:33] this way. Um I have uh uh applied open [16:37] source uh sorry security scorecard at a [16:39] variety of clients probably five [16:41] different clients um and I find it [16:44] extremely useful. Um and what I use it [16:47] for is I get a score a scorecard [16:50] manually. I run it in the CLI. I make a [16:53] list of the issues uh and then I get [16:56] them into the road map and I walk them [16:58] through the road map. And that's a [17:00] process that doesn't require redoing [17:02] once a day. I can do it manually. I can [17:05] come in as an expert and spend a week [17:07] figuring it out and then I do eventually [17:09] get them all touched and you can do the [17:11] same thing. So my recommendation to you [17:14] for scorecard is be aware of the metrics [17:17] and do it manually. Here's what that [17:18] would look like. [17:21] Uh I made up a scale that is amendable [17:23] to doing it manually. Okay. Me and this [17:27] needs fixing. Um and you know for you as [17:31] an expert you especially for an [17:33] engineering manager a senior manager a [17:35] senior engineer client who would be here [17:37] like you can make that sort of [17:38] assessment pretty well. Um and then I [17:42] extended the metrics that we saw before [17:44] to cover the inner source uh issues the [17:49] issues that are specific to inner source [17:52] security. And you notice how flexible [17:54] this framework is. It was really easy to [17:56] do this. I took each of the tests we [17:58] talked about, each of the threats we [18:00] talked about, and I added a category for [18:02] it, and I'm going to track it. I'm going [18:04] to evaluate it and track it and get it [18:07] fixed. So, it's a low tech way. [18:10] Automation is great, but you know what? [18:12] Getting it done is what matters, and [18:13] it's not that hard to do it by hand here [18:14] and there.