Fudge Sunday - Needle in a Fullstackby Jay Cuthrell
The Velvelettes “Needle in a Haystack” (1965)
Software Composition Analysis (SCA) is a method for looking at all the code that wasn’t written (by you or your team) but was inherited from somewhere else externally along the development journey and now represents a dependency. Or, to understand why SCA is important, please consider Dependency aka xkcd 2347.
🎶 I’m tellin’ you the natural facts 🎶
Application Security Testing (xAST) is a generalized approach for static (SAST), dynamic (DAST), or interactive (IAST) scanning methods when testing for vulnerabilities. Now, if this sounds like a shift-left disruption ready market, keep reading.
Run-time Application Security Protection (RASP) can be a specific wrapper approach that assumes a specific known context for the internal design of specific software. The RASP approach also enabled the creation of the Web Application and API Protection (WAAP) market because everything that could become an API will become an API on a long enough timeline.
Examples of companies from A to Z in this space include (with deep links to an educational blog post) AppDome, Checkmarx, Contrast, Data Theorem, Imperva, Invicti, Micro Focus, Onapsis, Qualys, Rapid7, Snyk, Synopsys, Veracode, WhiteHat Security, and Zimperium. And that’s just to name a few.
Interestingly, DevSec related features are increasingly appearing as partner integrations (and likely as an eventual native competitive parity offer) within collaborative code services such as GitHub and GitLab.
These approaches can be helpful in trying to find a needle… in a fullstack. Right?
So, what about about when the build breaks? Or you just inherited responsibility for a new (to you) codebase that was assembled over a time period longer than your entire career? Or your DevOps and DevSecOps teams are shifting their entire approach to everything in order to embrace an Infrastructure as Code (IaC) ethos?
In many companies today, lines of code written decades ago are still deployed in user-facing applications and are often barely holding massive Jenga blocks together. – Rahul Krishnan, Arjun Rakesh, and Ruchin Kulkarni
It’s fun but true story time. My first use of Sourcegraph was a year ago.
It was the umpteenth time to find what I did that broke the builds for my Gatbsy based blog. GitHub, Visual Studio, and diff were not helping me – but Sourcegraph let me know it was my lack of attention to detail in edits to package.json, gatsby-config.js, and the working environment where I had failed to run
yarn update @mdx-js-some-really-important-dependency-thing.
Like the Jenga blocks analogy from Top of the Lyne, if you’ve ever dealt with SCA or xAST tooling, then you’ll be familiar with the need for knowing how to manage compliance posture and addressing security concerns.
So, if you haven’t taken a good look at Sourcegraph, you should. Beyond the “X for Y” cliché of “google search for code”, using Sourcegraph is a paradigm shift in approaching and interacting with any existing or new codebase across the lifecycle of both contributors and the code itself.
Open a new browser tab. Search for Sourcegraph – you’re welcome. 🤓
🎶 Still water sometimes runs very deep 🎶
If software is eating the world, then the world is fast becoming an ever larger and ever more varied collection of code. So identifying the costs of time to productive contribution for a new hire on sprawling high risk high probability high drama committee consensus likely to break the build global monolithic repository vs. discrete de-risked specific modular codebase that empowers smaller more autonomous distributed teams isn’t just a metrics driven mindset – it’s sound fiscal policy.
Nothing like using @sourcegraph to build @sourcegraph—we’re migrating from global CSS to CSS Modules and our frontend platform team is using Code Insights to track migration progress: https://t.co/1lRqYjLiwz
Granted, HN comments section are often on the mixed bag karmic spectrum of insightful to floating dumpster fire – but some can be real gems.
One smaller thing I liked in my career was a job where each new hire was given charge of updating, improving, and editing the “new hire” wiki, which was started by the old hands. It included a brief history of the system, glossary, tutorial, reference links, etc. New hires are expected to ask questions and improve/update it as they go along. Pretty darn useful. Meant most boring, repetitive questions were quickly answered from “cache.” – digisign
Now, imagine combining FinOps to DevSecOps in a deeper practice. And for your consideration, the newsletter is once again including a read and a repo to explore the eventuality of shift-left oriented FinOps DevSecOps combinations.
Recommended Read and Repo
Almost every aspect of the IT practitioner experience is moving towards wider adoption of Infrastructure as Code (IaC). As such, the notion of vulnerability in code is a topic NIST and other groups are focused on in the cybersecurity realm.
Sourcegraph has published Universal code search on GitHub for self-hosted projects. While most organizations will opt for a commercially supported approach, the repo approach is a fascinating part of the Souregraph strategy… which is also published!
I am linking to my disclosure.
✍️ 🤓 Edit on Github 🐙 ✍️
Get Fudge Sunday each week