Podcast
Join Viktor, a proud nerd and seasoned entrepreneur, whose academic journey at Santa Clara University in Silicon Valley sparked a career marked by innovation and foresight. From his college days, Viktor embarked on an entrepreneurial path, beginning with YippieMove, a groundbreaking email migration service, and continuing with a series of bootstrapped ventures.
Links
Follow Me
Follow Me
Join Viktor, a proud nerd and seasoned entrepreneur, whose academic journey at Santa Clara University in Silicon Valley sparked a career marked by innovation and foresight. From his college days, Viktor embarked on an entrepreneurial path, beginning with YippieMove, a groundbreaking email migration service, and continuing with a series of bootstrapped ventures.
Mastering OpenSSF Scorecards & SBOMs with Chris Swan
Play On
21 APR • 2024
59 mins
Share:
In this episode, I’m joined by Chris Swan from Atsign to explore the evolving landscape of open-source security. Chris’s experience with end-to-end encrypted connections and his work with the Open Source Security Foundation (OpenSSF) offers unique insights into how we can better secure our software supply chains.
We start with a deep dive into Scorecards, an OpenSSF project that helps organizations demonstrate their security practices. What particularly caught my attention was how Atsign has used Scorecards to address customer security concerns, especially for their open-source repositories. Chris’s explanation of how Scorecards evaluate everything from dependency management to CI/CD practices reveals the practical impact of these tools on everyday development.
The conversation gets especially interesting when we explore SBOMs (Software Bill of Materials). Chris breaks down how these inventory lists of software components are reshaping supply chain security, driven by recent executive orders and growing security concerns. His insights into the challenges of SBOM tooling and CI/CD integration highlight the practical hurdles teams face in implementing these security measures.
I was particularly intrigued by our discussion of NIST 2.0 and its implications for cybersecurity frameworks. Chris’s breakdown of how governance and modern security paradigms are evolving shows just how much the security landscape has changed. We also explore Atsign’s open-source SSH NoPorts project, which offers a fascinating approach to remote administration without open ports.
If you’re interested in software security, supply chain management, or the future of open source, you’ll find plenty of practical insights here. Chris brings both deep technical knowledge and real-world experience to the discussion, making complex security concepts accessible while maintaining their technical depth.
Transcript
Show/Hide Transcript
Today's guest on the show is Chris Swan, an OG from the London tech world and we first met many years back and I bumped into him most recently at State of OpenCon in London where we're both speaking at State of OpenCon.
Chris gave a talk about Open SSF scorecards and I really got intrigued by this concept and afterwards I had a lot of questions so I asked him to come on the show to explore this subject a bit further.
So welcome to the show, Chris.
Thanks Victor.
And perhaps for the viewers, perhaps you can give a bit of backstory about yourself, your experience in tech and basically who you are for sure.
So I'm presently an engineer atSign, that's a company where we're building a Networking 2.0 platform that helps people connect to things and entities and other people over end to end encrypted channels through personal data services.
That's obviously security critical functionality which is what got us into OpenSSF and scorecards.
Going back a little further, I started my career in the Royal Navy as a combat systems engineer, found my way from there into sort of the end of the dot com bubble doing.com consulting which took me into financial services.
Spent a bunch of time in banks building large scale systems and then found my way into the startup world which I think is when our paths first crossed when I was at Cohesive Networks, so my first time around building next generation networky things.
So at the time networking for the cloud and bringing containers into networking.
Since then I spent a bunch of time at CSE and then DXE in the IT services world, but kind of happy to be back at the coalface cutting code in startup land.
Yeah, definitely got a lot of experience there to bring to the table, so maybe we can start.
For people not familiar with OpenSSF, it's a relatively new organization or entity I guess maybe.
Can you give some more backstory what OpenSSF is?
I know you're not directly involved, but just to give some more backstory of what that is to start with.
Yeah.
So OpenSSF is the open Source Security Foundation.
It sits within Linux foundation, so it's kind of there alongside of perhaps more familiar organizations like Cloud Native Compute Foundation.
If I kind of look at the primary movers, there's an awful lot of energy initially seems to have come from Google and so I think Google has been on a mission to lift the bar for everybody on security, but also to show that what they're doing and what they're building is secure.
So this is where I first came across Scorecard.
So A little while back, the Dart and Flutter projects, which we make a great deal of use of at Sign, did a blog post about how they'd adopted Scorecard and put scorecards onto their repos.
And this immediately seemed to us like a good way of showing people that we care about security.
So I saw Google using this as a way of saying, here is a badge on our repo, which is showing you a visual indicator of we care about the security of what we're putting in front of you here.
And so we adopted it for similar purposes as a way of showing that we care.
And when I'm talking to our sales guys about this, they say they get questions from potential customers about security and they point at the scorecards, and that's very often the end of that conversation.
The prospect's happy that they've been shown something that gives them confidence that we're doing the right things.
That's really interesting.
And then you guys at Sign, those are open source repos, correct?
Yes, they are.
So in that sense, it makes a lot of sense.
What about for private repos?
Can this be used for the same methodology for private repos and just show the scorecard number or some kind of manifestation of that?
Or is it purely open source?
I guess if it's a private repo, who are you showing that you care?
It can be the insiders in your own organization.
So there's really very little to stop you from using the scorecard on a private repo.
And I think the discipline that comes from kind of going through the exercise of getting a decent score on a scorecard is something that you would want to do as an organization anyway.
And so, yeah, doing it for private repos makes a ton of sense.
If I look at our own practice, a lot of the things that we do in our public repositories have now become sort of so baked into the culture of the organization that they're just part of how we do private repos.
Anyway.
We've not gone as far as actually implementing Scorecard on private repos, but we're sort of beneficiaries of having done it on a chunk of the public repos.
So it's more like it has driven a cultural shift or a behavioral shift across the teams to even to apply the same methodology across private repositories.
Absolutely.
Yeah.
Okay, so that's really interesting.
Let's dive in and unpack a little bit what an SF scorecard is.
I know we probably gotta dive into demo in a little bit, but before we dive into the actual demo.
Maybe we can start with like what constitutes the scorecard, what goes into it, what are the criterias and what's been picked up and so on.
So it's looking at a bunch of different measures to produce a composite score.
So things like dependencies.
Are you diligently managing your dependencies?
And one of the things that it can go and measure there is are you pinning your dependencies to Shars?
Right, right.
So not only version, but even sha's.
Yeah.
Okay.
And so it's looking then into your GitHub action workflows, your lock files for the package managers that supported, and checking that you've got things pinned to Shars there.
And so you need to do that to get a score of 10.
So that's just one piece.
Another piece would be are you running CI and doing automated testing, are you doing static source code analysis or are you doing dynamic source analysis?
And how does it do this?
Does it look at like, oh, I'm using Sonar Cloud for automatic audit, or I'm using Dependabot for mobility scanning.
Like how does it actually pick up on those variables?
So it's got a bunch of, I guess, the commonly used tools applying to the commonly used language and frameworks that it's able to go and measure things.
There are definitely white spaces around that.
And being an open source project itself, there are routes for people to contribute and get their preferred tools into the fold.
So it's not entirely covering every single possibility, but with the stuff we've done, and we're a little bit off the beaten path with a lot of stuff in Dart and Flutter, we quite often find that there's not, for example, tool support in LaunchDarkly or Honeycomb or Snyk for Dart.
And yet we've found that, and maybe because of the effort within Google to get Dart scorecarded, it is actually reasonably well covered by the Scorecard framework.
And so the only place that we really run into trouble there is on dynamic analysis, because that's normally third party tools.
And so if you look at Dart itself, it's using an open fuzzing project.
But that's kind of unique to Dart itself.
It's not like I can pick up that open fuzzing project and apply it to my use of Dart.
So you end up with a few things that are difficult to accomplish.
And that kind of leads me into one of the measures is compliance to OpenSSF best practices, which were previously called CII best practices.
And that's quite an extensive questionnaire that you can sort of fill in on an online form.
And there's three levels there.
So there's a sort of passing level which gets you, I think a score of five and then there's a silver level and your score goes up a bit more and then there's a gold level.
And even just getting a passing score is a lot of spade work.
So that was one of the things as were implementing it initially.
We kind of filled out those forms as a sort of first pass at here's where we are.
And it gave us a measure of okay, there's a bunch of things we're going to have to go and do to actually finish here.
And these are like, yes, we're using CI more like a subjective assessment or like, yes, we have a unit test, yes, we have integration tests.
Are they actually going like, what's your code coverage or to what degree?
So a lot of it is simply questionnaire.
It does ask for evidence and I think where people provide evidence, then that provides a bit of an audit trail for anybody coming and checking their homework, especially where it is open source and they can go and look at the repo and see that thing has actually been implemented.
Right.
So if you take something like testing, one of the questions would be, are you doing tests?
And you can say yes.
But another question might be something like, do you have a policy that new tests should be added every time you add new functionality and you may have a document that contains a written down version of that policy?
Or you might more informally have an expectation in a dev team that's just how we do things around here.
Yeah.
It might even be evidenced in not one place, but in a series of PRs where it's sort of, you can see the tests are there or you can see that when the tests weren't there, the PR reviewer was saying, what about tests?
Right, right.
Okay.
Yeah.
Because I think, I mean, we are starting to emerge more like a blueprint for how software is built on GitHub today, with GitHub Actions now becoming kind of the blueprint for at least for a lot of companies out there using.
So I guess you can infer a lot from.
Based on just parsing the YAML files from GitHub Action, see what you're doing.
But it sounds like you're almost getting into compliance territory like socarize or whatever when they ask for evidence and so on.
And with regards to, with these workflows, does it infer things like you require pull requests and you require to merge to master, you require more than One review sign commits.
Does it go into that territory as well, or is that.
Absolutely.
So one of the areas that it looks at is branch protection.
Okay.
And so it'll actually look at the detail of the branch protection config on your repo and it'll specifically award marks based on a bunch of the things that you just rattled off there.
So if you are not mandating reviews, then that's a big thing.
If you're not having mandatory tests, that's another one, and so on.
So there's certain things that it's not very pushy about.
So signed commits.
I could choose to have mandated signed commits.
I think that's not something that's particularly friendly in an open source community.
With the new changes at GitHub though, where you can actually use your SSH key to sign, which I think is kind of moot, but you can do it.
I guess the bar is slightly lower than having to set up PGP for that, I guess.
But yes, it absolutely is.
And certainly that's my preferred way of signing commits these days.
Yeah, but that's some.
That's one of the areas where I'm glad it's not a measure in the scorecard as yet, because it's.
It's something that I'm not super keen on inflicting upon, you know, every.
Everybody that wants to come along and make a pr, especially when we get into, you know, the Hacktoberfest type of contributors, where you're very often dealing with people who are new to open source and just trying to get started.
Yeah, I mean, and that's spot on, I guess, for open source projects.
Probably less important, more like as a corporate policy, for instance, that's cleanly.
We require signed commits for everything that goes into our repos, but we can control that because they're all employees.
Whereas if it's an open source project.
Very different.
Yeah, I completely agree with that.
And then talk to me for a bit about language support, because a lot of these things are language specific.
Right.
You mentioned Dart and Rust, but Dart and Flutter.
How about other languages like Rust, Python, Go?
What's the ecosystem like for those level of features?
So it's reasonably well covered.
If I look at the languages we've been working in, we're quite polyglot because we're building a protocol and a platform and providing a whole bunch of SDKs to support that.
So I've been working with stuff in C C, Java, Rust, Go, Python, Micropython, and so all of those seem to be reasonably well understood by the scorecard.
Some of those are challenging in terms of again things like dynamic analysis tools.
So where you're kind of on the well trodden path with languages like say Java, then the route is very clear.
You could go and pick from a whole range of dynamic analysis tools and you'd be good with that.
Yeah.
Whereas with some of the less traveled areas, Micropython springs to mind, you're a bit more sort of on your own with that.
Or it may just be that you can't actually do dynamic analysis and you just have to accept that.
And you getting a score of 8 which gets you a green badge.
I think there's a bit of a Pareto thing to this.
So I think it's kind of 20% of the effort to get 80% of the score.
Right.
And then it's all uphill from there because it's 80% of the effort to get the other residual 20%.
And so yeah, I'm quite happy that our range of scorecards is all sort of in the eights.
Eight upwards.
Getting nines and above is really super hard.
And you don't even see that on the Google Repos or even the OpenSSF's own repos.
And so good luck to people trying to accomplish that.
And 10 kind of is almost a horizon objective.
You could do it in hello World, but a real project might be difficult.
Right.
Well, so actually even hello World, you'd have to put so much stuff around hello World to get that.
How are you going to test hello World?
Where's your it prints it.
Great.
Yeah.
So yeah, actually you can test hello World pretty easily, but how are you going to fuzz it?
And so if you've got the right language, then of course you can just wheel out a fuzzer and say I'm going to fuzz my hello World.
But if not, a bunch of these things are fairly challenging and a lot of the stuff, especially when it gets to how are you going to get gold on the best practices is getting into questions of organization and culture and policy about how you do development as much as it is artifacts in front of you.
Oh.
So it goes into how you run your team, how you do agile and so on as well.
Not quite that invasive because I think it has to be very accommodating to, you know, different strokes for different folks.
But then again, as I kind of go through those questionnaires, it feels to me like there's a lot of bias towards sea, for instance, that there's a whole bunch of sins of the past have been committed in C development.
And so there's a whole bunch of best practices to make sure that we're not repeating those sins of the past.
And of course, if you're using something other than C like Rust and so memory safety isn't the same concern as it was before, then you're maybe answering not applicable to those questions, rather than, yes, we're doing this stuff to make sure that we're not repeating the sins of the past.
Right.
So it sounds like it's opinionated by a lot of things with regard to things like linting and best practices.
Is that also covered or is that separate entirely?
So linting is definitely a piece of the puzzle.
And it's one of the things that's got me doing markdown linting for our docs repos.
That is a pain in the ass.
I've done that.
And it's definitely counterintuitive.
When you start doing it, you get.
Used to it, but yes, exactly.
And I think you do get used to it.
And then these become sort of norms in the organization.
And so I've recently seen colleagues now submitting nicely linted markdown.
Even in the repos where we don't have automated markdown linting because it's becoming part of their standard tool workflow, it's sort of, oh, I've written some markdown, so let's just lint it before I do a commit with it.
And it's kind of great to see that discipline taking hold.
If I go back to sort of earlier in our journey, then we introduced conventional commits and semantic PR to check that people were doing conventional commits.
And at first that was a bit of a lift for the organization.
And especially as we had new people coming on board, less experienced interns and the like, it was sort of, oh, I don't understand what this thing is, and so I'm not going to do it.
Whereas now it's just so embedded in how we do things.
My favorite definition of culture is the way things work around here.
And so conventional commits is part of the way things work around here at Sign.
And so even though we've never mandated it, we have the Somatic PR check installed as an app, and it'll show the horrible little red cross for anybody that hasn't done a conventional commitment.
And we've then seen that as a whole generation of interns has flown through the organization, the people before them, kind of getting them started, just said, this is part of how we work around here.
And it kind of happened much more organically the other thing thinking back a bit was the implementation of All Star, and this is another OpenSSF project and it's something that I think is a good foundation to doing scorecards.
So this is again, an app that can be installed into a GitHub organization.
There's a certain amount of config can be applied to it from a dot repo, but it's looking for some of the same things as a scorecard is.
So do you have brand protection?
Do you make sure that you don't have binaries in your repos, have you got a security MD and these kinds of questions.
So a bunch of it is about repo content and a bunch of it is about repo config.
And so it's checking across those areas and it'll automatically raise issues if something is found or if something reoccurs.
So, for example, start of the year we had the CES show in Vegas.
One of my colleagues went off to there.
We were demoing some stuff with our partners at qt and he came back and very enthusiastically kind of checked in all of the demo code.
And in amongst that, I think it was Python, was a whole bunch of compiled Python.
Right.
And so immediately the All Star checker kind of then reopens the issue on the demo repo as a, we shouldn't have binaries in here.
And it's kind of, do we need that binary there?
No, we don't actually need that binary there.
So we can go and purge it.
So one of the things that, in my experience, at least when applying security, or I should say automated security, I guess, with pull request checks and whatnot, is that it always, at least in the beginning, introduce a fair bit of friction before people are used to it.
Right.
And in particular, when you need to get things out fast, it's always a trade off between speed of delivery and being secure.
What has been your experience around that?
Because I mean, at least in my experience that there is a pain point around that as you start, at least before it becomes how we do things around here, but at least before you get that point in terms of how much did you feel it slowed things down.
So we've not done much to the sort of mainline path through, you know, continuous delivery pipelines.
And I've always had a target of 10 minutes, the sort of Dave Foley approach.
People should be getting feedback quickly enough that they're not context switching out of the work that they were doing.
Right.
And actually, you know, I generally try and orchestrate the pipeline so that they're Completing in less than five minutes.
That's doable for smaller projects.
But if like a very big project, it's very difficult target to meet if you have a lot of code needs to be compiled, for instance across platforms and whatnot.
Yeah.
And so we try and carve things up into small enough chunks that we are looking at small pieces and getting that quick feedback.
The scorecard itself is just another parallel GitHub action workflow.
Right.
So it's non disruptive.
What's occasionally happening there is, you know, colleagues are doing work that ends up digging the scorecard and then there's some follow up remedial work to get the score back to where we want it to be.
Right.
So you don't have as an acceptance criteria, you block it.
If somebody pushes something that drops a score, you would do as a follow up task rather than a hold on, you cannot allow to merge this pr.
Yeah.
So it's not implemented as a kind of pre check on a pr.
It's more as things are being merged to trunk.
It's constantly updating to reflect the reality of what it finds there.
Right.
Okay, that's fair enough.
So we covered a couple of the basics of what it is.
Do you want to dive into maybe a demo how this actually works?
Because I think that would be a super interesting way to show people how this actually works in the real world.
Because we talk about theory behind it, but seeing the code always makes it easy to understand it.
At least I find it.
Yeah, I can do sort of a quick walkthrough.
So let me figure out how to do a screen share with this thing.
There we go.
All right, so this is a summary page that we have off the profile for at.
And these are the repos that I kind of called out from that profile.
And so each of those has got an accompanying scorecard and we just do a little table here to show them all off.
And so I'll jump into.
So this is the implementation of our personal data service.
And this was the first thing that I implemented scorecard on.
So I suggest to people that they kind of find a representative repo when they're kind of first doing this and cut their teeth on that representative repo and then kind of rinse and repeat the same processes across the rest of the repos that they want to do in their organization.
Actually this one turned out to be maybe a bit harder than being representative.
So the work involved in doing this one was maybe more than some of the others that I could have chosen, but perhaps actually that did make it a good place to start because once I'd done this one, it was pretty much all of the rest after that were actually easier.
So I can see the scorecard itself here and that's showing a nice green badge and a score of 8.9.
If I was to click on that scorecard, it'll take you into this results file.
So this is a SARIF file that's been generated by the last actions run.
Obviously this is just an eye chart of JSON, which is pretty difficult to make sense of unless you have got tools to pick it apart.
So we can also look at how that got generated in the first place.
So going into my GitHub actions here, we can see that we've got the scorecards supply chain security action that's running every time we're having a commit being merged into trunk.
And so all of our PRs are doing this scorecard analysis.
And I can have a look at what actually went on in that.
So you know, it's pulling the action from Google's cloud registry.
The main sort of work is happening here as it does run analysis.
So that entire analysis only took 31 seconds.
That's pretty quick, actually.
Is there a separate work?
Yes, and it's because it's not doing the tests, it's looking for the evidence that the tests are being done.
Right.
And so if I was to take something like static source analysis, it's not doing the static source analysis, it's looking for the fact that the static source analysis is happening.
So it parses your GitHub Actions workflows, I presume to look for that.
Absolutely.
And yeah, so you could be.
If I go into one of the other repositories I think might be a good example here.
If I look at closed PRs on this and actually I've picked the wrong one.
I knew it was a C language one, but I think it's this one here.
And this is just a docs one.
But we're using SonarCloud.
Right.
And some of the tests that we wanted to do for this ESP32 flavor of C, I wasn't finding an open source tool that I was comfortable with.
And so we're using the sort of open source enabled version of the Sonar cloud service in this case.
And so the scorecard is consuming the output of Sonar cloud as part of building.
Okay, so using.
So if that quality gate failed, it would pick up on that.
Okay.
Yes, it would.
Okay, so that makes it slightly more intelligent.
Than just checking that you actually do have some tooling in place.
Yeah.
Oh yeah.
It's not just looking have I got the tooling?
But what is the tooling saying about the environment that it's finding?
And so it's going through that whole range of checks and actually it's good to visualize them.
So one of the Linux foundation folks put together this Scorecard report app which visualizes them on a radar chart here.
And this gives us quite a nice way of walking through the various things it's looking for and the score that's kind of coming out of this particular run that happened.
So binary artifacts.
We touched upon branch protection.
We talked about CII best practices are those questionnaires.
And so you can see there that there's a passing score but not gold, whereas pretty much the rest of it is looking 10 out of 10 there.
So code review contributors, dangerous workflows, dependency update tool.
So all of those checks have passed fuzzing were absolutely nowhere.
And this kind of comes to that.
There isn't really a fuzzing tool I can deploy against Dart code at the moment.
So it's found a license, it's found evidence that the whole thing's maintained.
It's happy with how we're doing.
Packaging PIN dependencies is almost a 10, so there's a slight ding there.
Static source code analysis is happening.
In that case, Dart has a built in Dart analyze and so we can simply run that and feed it that we have a security policy.
We're not doing signed releases.
And so that might get us into some of the other OpenSSF projects like Salsa and various tools around building software, bills of material and signing artifacts and.
Those sorts of things and signing releases.
So that's just not merely like signing a git tag, it's more than that or it's more comprehensive than that.
If you do it git tag it and release and that sign, that's not sufficient for the signing process.
It requires to go further than that.
Yeah, that's about taking the package that's the result of what you're building here and signing that package in a way that's going to be meaningful to a consumer of that package.
Okay, so it can still be used standalone to inspect, essentially.
Yeah, got it.
Okay.
Okay.
So this obviously gives you a good overview of where you stand.
And you said this is an open source project from the OpenSSF project.
Yes.
Okay, that's really cool.
So the other thing I wanted to dive in on, which is kind of, you gave me a really Good segue into that is sboms.
Right.
Because that's.
Well, there are a lot of talks around that.
And not least at the conference at the State of Open, there were a lot of talks around sbombs and where.
Well, I guess maybe we should start with what's SBOMs and why should people care?
So an SBOM is a software bill of materials.
And what it's doing is saying, these are the components that I've used within the software that I am providing to you.
Whether that's open source or whether that's a commercial product.
People should care because you don't want to be using things that have got known vulnerabilities in there.
And the SBOM really provides the mechanics for knowing about those known vulnerabilities and whether a given thing is carrying known vulnerabilities with it.
This really came about from a number of people in the security side of the industry focusing their attention on the US Federal government.
Initially, what they were trying to do was get a law passed through Congress which would essentially say if the federal government is buying something, then the federal government is going to insist on a software bill of materials.
And if inside of that software bill of materials, it's clear that you're selling something that has known vulnerabilities in it, then that's probably going to be a.
Problem that would most certainly annoy a lot of legacy vendors.
Yeah, so that's not what happened.
What ended up happening was rather than a law being passed through Congress, there was an executive order issued by the Biden administration which is having essentially the same effect.
So it's still providing a mandate for federal purchasers to.
To require software bill of materials from their suppliers.
And so swinging the searchlight onto our suppliers, selling things to the government that contain known vulnerabilities, and what are they doing about that?
Now, this was done from the very start with the sort of notion that if this was being done for the federal government, then it would drag kind of everybody else along with it.
If everybody supplying the federal government had to do this, then they might as well make their software bill of materials available to all of their other customers.
And so everybody would benefit from supply chain transparency and knowledge of what's inside my stuff and what's got known vulnerabilities in it.
This then gets you into building a set of tooling and processes around.
Okay, when I looked, when I bought the thing, it had no known vulnerabilities in.
But we're discovering new vulnerabilities every day.
And so are there now vulnerabilities in because there's new stuff being found and if so, you know what's happening to resolve that.
Right.
You know, is the thing being patched and am I having to redeploy the patch version or am I having to put other mitigations in place in order to compensate for the known vulnerabilities that I've got in the overall environment?
And I mean, and from my understanding there are like debates happening right now about what the NASPEN should look like.
There is no gold standard to this date about what NSPOM looks like.
It's some form of JSON usually, but I don't think there is a complete standard for how that looks like to this day.
Right.
So there's a couple of popular representations of SBoMS.
And so the tooling as it stands today tends to use one or other or both of those as an input and will normally be consuming a vulnerability feed which will be based upon CVEs but may also be including other sources of vulnerability.
And so that's helping people take a look at what they know that they have and what they think is potentially going to be wrong with it and then make risk based decisions according to the vulnerability that reveals and then their overall threat model and risk posture and other considerations that are going along with that.
Right.
And if you generate, I mean I would imagine you would always generate these files in your CI CD pipeline as part of your release build, right?
Where you build a, well, semantic versioning and you have, as part of that release you have an SBoM, right?
And then you provide that to your customer essentially and say here is the SBOM for this particular version and I would imagine then fast forward into the future a little bit.
That file would then be uploaded to some kind of monitoring tool.
So that would use data like sneak or something similar to scan that dependency list against then and then flag that there are vulnerabilities.
But with every new version of the software, imagine in the case of Screenly, for instance, our signage players upgrade automatically as soon as we push.
Essentially there's a canary place to it.
But that snapshot was only relevant for that release, so that you have to constantly provide new SBOMs with every new release.
Right.
So there's a lot of moving parts.
Have you seen any tooling around that accommodate for that moving part of it?
Yes, I have.
So this is a very sort of hot area at the moment.
So there's a lot of developments happening with tooling to help people understand what they've got Understand where the vulnerabilities lie and what they've got.
Keep up to date with both.
So as you say, the SBOMs are going to be constantly iterating, especially where people are consuming stuff from the end of somebody else's continuous delivery pipeline.
So in something like your case, where you're making very frequent updates to production systems, the SBOM associated with that is going to be, you know, tumbling over pretty rapidly.
And so one of your customers concerned about vulnerability would hopefully see a process where a CVE gets raised.
There's a known vulnerability in probably not even the code that you're writing, but a whole bunch of the underlying dependencies.
And so that will initially raise a red flag and say, I'm now dealing with vulnerable software.
But at the same time you'll be getting notifications into say, dependabot saying there's a known vulnerability, you need to bump to this version.
You crank the continuous delivery pipeline handle, it spits out a new set of artifacts, it's got a new SBoM saying, I'm now using the known non vulnerable version.
We're all good here.
Now that's a very simplistic telling of the story though, because where all of this gets problematic is if I'm using an underlying dependency as part of software that I'm shipping and it becomes a known vulnerability, but it's not fixed immediately.
But I'm not even using the bit of it that's broken.
Right, right.
This comes back to like the vulnerability checks in general.
Right.
And that's where it gets really murky.
Yeah.
And so that more sort of nuanced analysis of I've got a known vulnerability, it's not getting fixed immediately, but it doesn't matter because my code isn't using the methods that are understood to be problematic, then actually all is still well in terms of that particular product.
But the ability to measure that and articulate that is because of that additional nuance, much harder to reach at the moment.
And so I think because we're in the early days after the executive order and the early days of building tools to deal with that, we're still in sort of the black and white case of are there vulnerabilities or are they not?
And I think there's a whole bunch of especially open source, where things are moving pretty quick and that stuff gets fixed.
That's great.
So say Python cryptography, you know, we use Python cryptography is at the heart of what we do.
So of course we use the cryptography library.
Right.
That thing is being patched on an almost daily basis.
Yeah, we use it too.
I know.
And so, yeah, CVEs happen.
The team are super responsive to that and new patch releases come along to deal with OCVs.
And as I look at those, you know, it's not quite daily, but it's probably a few a week bumps to Python cryptography.
It's maybe half of them are security related and half of them are functionality related.
And sometimes it's like, oh, they fixed the security bug yesterday and that led to some other corner case functionality stuff that, you know, maybe wasn't being highlighted in the previous test coverage.
And you know, everybody will learn and get better going forward.
Right.
And so there's another bump the following day which is dealing with the fallout rather than actually fixing a security vulnerability.
But those things are moving forward really super fast.
But then you get other dependencies where they're not as actively maintained and somebody flags up a security critical piece of problematic code, but the maintainer doesn't do anything about that at all or for months or whatever.
And that then gets you into, well, is it actually a problem for how I'm using that?
Yeah.
I mean that brings us up to the whole big debate on of all open source project builds, another open source project.
And at the end of the day there's always like one or two libraries that everybody uses that there are like two maintainers.
Like OpenSL stands like a good example of that when there were their vulnerabilities last year or the year before.
And there are like handful of maintainers that basically support all of the Internet.
Right?
Yeah.
And there are similar libraries that are used everywhere, but there's like one guy doing this on an evening and 500 or like 140500 depending on this.
As for their production environments.
Right.
Which raises debate on like how do we solve that for the future because somebody got to pay for this and a lot of people that make a lot of money are using them but not contributing whatsoever.
Right, yeah.
And I think that's probably a whole nother podcast's worth.
Oh yeah, absolutely.
The funding model for Open Source is fundamentally broken today.
Yeah, it's problematic.
I think one of the parts of the opening keynote at State of opencon kind of addressed that.
The whole question of what does a post open source landscape look like?
And I think enterprise users of open source and you know, services companies that build their value on top of open source could be doing more.
Yeah, no, I mean, I think you're right.
This should be another episode about licensing like Redis Springs to mind as a good kind of like David Goliath story.
Right.
Fighting against the cloud vendors.
Right.
But I mean the whole supply chain security side, I think it's very interesting and I think what we really, I mean, at least I'm envisioning a future workflow where as part of your CICD pipeline, you submit your SBOM to like a third party that you tag it with your sember or whatever and then that system will then integrate with enterprise vendors that you sell to.
And then if there is a vulnerability in something, your security staff at your company can sign off that say, hey, actually this doesn't matter because we don't use this code path and that's perhaps you can get around it.
That's at least how I would envision a workflow look like.
There's certainly going to be, I think, commercial opportunities on top of what people are building as open source.
And I also like the vision at GitHub on this, which was articulated when Nat was their CEO, that since most open source is in GitHub, they can actually see the dependency graph from end to end.
And so it's within their gift to build tooling which can track a taint all the way through the sort of various layers of dependency.
Oh, I would most certainly envision a future scenario where either GitHub built this or they acquire someone who has built it.
Like just to do with the dependable guys, right?
Yeah, because it just slots straight into their portfolio and makes a lot of sense for them to actually have an offering like this.
The last thing I wanted to cover, which is something that I'm not sure, you might have not covered that, but might not have seen that.
But NIST 2.0 was released last week or this week.
Was it the new NIST framework?
I'm not sure that you have any thoughts around that, given that it's the first Updates is like 97 to NIST, I believe.
I'm not sure you had a chance to look at that.
So I've very briefly taken a look at it.
It came up in one of the Zero Trust working groups that I participate in the other day.
And yeah, I've also been looking at various commentaries on what's different about 2.0.
It's worth just articulating what is the NIST Cybersecurity Framework.
And so this is really an almanac of security practices pieced together from NIST guidance.
So NIST in the past has released a whole bunch of guidance around things like authentication and authorization, but there's also a whole bunch of other industry standards in various areas.
So ISO 27000 series, COBIT, and so all of these things had things to say about organizations and approaches to security.
And the original NIST cybersecurity framework pulled them all together.
And so I always viewed it really as an almanac, having consolidated NIST and COBIT and ISO 27000 series and a few other things into one place.
It was in many ways the sort of building code for securing an organization.
And I saw the primary consumer of that as being CISO or CISO being able to pick it up and say, if I'm doing everything that's in the cybersecurity framework, then I'm doing everything that could possibly be expected of me.
I first came across it sort of in earnest back in cohesive days because at that time there was a certain amount of dialogue going on that the cybersecurity framework was really put out by NIST to be for government and especially federal government.
But I think it's been widely adopted by, in the US at least, a lot of state governments and local governments.
Again, I've seen it being picked up a fair bit up from the medical industry as well, so hospital and so on, like people that actually care about security.
They.
And I think at least my advantage point is, I think I covered this in one of the other episodes.
Like for me, ISO and SOC2, they are security for salespeople, but NIST is security for actual security engineers.
And I think that's how I see that.
And so it was being waved at the financial services industry in a way that there was some notion that the financial services regulators would start demanding cybersecurity framework compliance from the organizations that they were regulating.
That didn't actually happen.
And I think it largely didn't actually happen because the banks, et cetera, were mostly doing pretty much all of what was in there anyway.
And I don't think it would have substantially changed the dialogue.
So that was a decade ago.
And SO Cybersecurity Framework 2.0 released in the last few days is a refresh of cybersecurity framework.
Some are arguing not enough of a refresh.
And I think this is perhaps because Bruce Schneier observed many years ago, it's like the old attacks never die, and the old regulation that was born from the old attacks is also a permanent fixture.
And so if you're making an almanac, there's none of the old stuff that you really get to cut out.
And so when you get into conversations about shiny new stuff like zero trust networks or software builds of material or whatever else you may or may not add it in.
And so if I take something like zero trust, can I use a zero trust approach to put in place controls and monitoring regimes for those controls that will allow me to show evidence for achieving certain areas of the NIST framework?
Absolutely.
Does the NIST framework still mostly read like it's expecting you to do traditional networking with firewalls and hard on the outside, soft in the middle?
Maybe it does, because not a great deal has changed there.
The big change is the introduction of a governance section to the framework.
And I think if you go back to the initial release, there was a sense that was a missed opportunity and it's one that's been resolved.
And of course, sorry, what does that.
Actually mean in this context?
What do you mean by governance in that context?
So if you look at the framework and the areas it addressed could be portrayed as a wheel.
And as he moved around the wheel, there were different things.
So a bit like the radar chart I was showing for the scorecard a few Minutes ago with CSF2, there's now an inner wheel of governance, which is to say all of the aspects of the cybersecurity framework relate to a set of governance activities and supporting processes to bring everything together.
Okay, so in terms of SBOMs, you said that's kind of.
It's still.
Flaggers are nice to have or is it something that you reckon is going to be pushed?
Haven't got into that detail.
So the SBOM is being pushed by the executive order.
The NIST Cybersecurity Framework 2.0 was something else that NIST were told that they had to get 2.0 out by, I think, April next year.
So they are way ahead of schedule.
But this is a final version, it's not a draft.
Right.
So yeah, this is the final version.
This is 2.0.
So I think it's gone from 1.0 to 1.1 and it stayed the same for a very long time.
And then not directly from the, I think the same executive order that brought us SBoM, but from a related executive order.
NIST were tasked to update the cybersecurity framework.
Job done.
They have.
Have I had the opportunity to delve in to see whether things like SBOM are now being explicitly referenced in there?
No, that's not an opportunity I've had yet.
And again, I don't think it matters much either way because the SBOM has got, I think, enough momentum behind it with the executive order.
But also everything that's happening at Caesar in order to help ease the implementation of the executive order.
Yeah, we actually had our first customer request for nestbom at Screenly last week.
So it is actually starting to happen with a big medical group.
So it is starting to happen.
So it's actually not only theoretical anymore, it's actually part of compliance for very savvy customers, I guess.
But very early days still, I would imagine.
So you probably saw the panel at state of OpenCon that was preceding my talk about scorecards and there was a handful of practitioners who were each working inside of organizations on their security.
And what I was hearing from all of them is that they had mechanisms already in place to consume SBOMs, to analyze SBOMs against their vulnerability feeds, and to take various actions against their threat models and risk profiles to deal with what they were receiving from that.
So it is early days and they were probably there on that panel because they're advanced practitioners and not.
Oh yeah, those are very savvy companies, all of them.
Right.
So they're not like your average company.
Right.
Chris, this has been super interesting.
Thank you so much for coming on the show.
Do you want to do a quick shout out to Sign where people can learn more and perhaps learn more about anything you want, really, before we wrap up the show?
Yeah.
I think something that the audience for this will really appreciate is a thing that began as a demo that we built at Sign for the platform, but has turned into a product.
So SSH no Ports is a tool we've built for people to do remote admin.
We've got people using it for things like home labs, but we've also got organizations using it to deal with field deployed Internet of Things type devices.
And as the name suggests, you can get an SSH console onto a device with no ports open, but also things that move around networks and stuff.
So I'd encourage people to just check that out and have a play.
And it is also open source, which I think is important to highlight in this context.
For sure it is open source.
Yeah.
Perfect.
Again, thank you so much for coming on the show, Chris.
Very much appreciate it.
Talk to you soon.
Thanks, Chris.
Found an error or typo? File PR against this file or the transcript.