Late Night Thoughts: Lessons That Stay with Me

Every couple of months I find it interesting to look back on some of the key takeaways that really cemented themselves in my brain. Sometimes it’s a weird conversation that I just can’t forget, other times it’s something that keeps coming up again and again. I don’t know if you’re like me, but sometimes I’ll be awake in the middle of the night, unable to sleep, just reflecting on situations and making new realizations before looking at the clock and seeing 1:37 staring right back at you blinking.

One such repeat though is Google engineers must be really hungry (or have the munchies) since they like to name things after food. SLSA (pronounced salsa) and GUAC are some of the new standards I’ve become aware of and I’m waiting for DIP and CHIP to join their ranks shortly followed by HUMMUS. What I find most interesting about these terms isn’t their name, it’s the number of people I speak to who need to implement these standards in some way to secure their software supply chain. In short, don’t just trust or think about what you run or where it came from, think about how it was created, who created it, and how secure their build process is. If you are using code that someone else has built instead of building it from source yourself you don’t have full control of what you are putting into your own project. I’m very guilty of this when I was in University just trying to get a project completed that I had procrastinated on and needed to be in before midnight. In some cases, I very much recreated the XKCD Python Environment. https://xkcd.com/1987/

People put way too much trust in scanning tools. As it turns out it’s incredibly difficult to accurately scan a compiled file instead of scanning the source that went into the build itself since AI isn’t much better at resolving encoded libraries than we are. Additionally, not everyone has insight into what their packages and projects depend on down to the transitive dependencies (the dependencies of your dependencies). This is a lot of work and can often take a lot of time for developers to fully vet when all of their metrics incentivize them to just get something working and worry about it later. Some companies will put in the time and effort to manually vet and build everything from scratch but that is few and far between. And since many devs may need to include an additional package from time to time to mitigate a new vulnerability or include a new feature, often things are done after rather than before. There aren’t a lot of options on the market that truly build everything in a secure manner while saving time and effort for development teams. I know this sounds like a sales pitch, but just think about how much time you would save if every time you had to update a package it was just a single click. Including the ability to generate SBOMS, Attestation documents, and CVE dashboards/reporting from a single click or call in the command line.

This actually brings me to my next point, SBOMs and Attestations are going to be required in September of this year for any company providing critical services or infrastructure to US Gov agencies. I’ve had conversations with a few contractors working with governments where the governments themselves don’t even have these procedures and processes in place. Software provided to Federal agencies will require this level of information and identification (EO 14028 for more info). Basically are you able to say for certain where something came from, how it was created and consumed, and what exactly went into it? Before learning that there are some tools out there to help, I always thought it was just left to the documentation developers created. Not to talk down on any developers, I have a huge amount of respect for them, but nearly all of them would rather just code and solve issues than write down anything about it. To a developer, comments are like putting a summary at the beginning of each book chapter; if you want to know what it’s about, just look at the code or read the manual about how to use it. At best it’s comments/documentation written for other developers unless you hire a technical writer to convert it to layman's terms.

And now if you are wondering why these are the most interesting items I've had to learn, it's because as you may have guessed, ActiveState solves all of them. From automating your CVE dashboards to making sure your supply chain remains secure and fully visible, our platform is being used by over 90% of Fortune 500 companies. If you don’t yet have a solution for your software supply chain, feel free to leave a comment below or message me directly so we can chat.