2021 was a CRAZY year!
We spent most of 2021 at home. We had to build new ways of working and migrate things to the cloud WAYYY too quickly. We saw new types of threats to our applications including “dependency confusion attacks” and “software supply chain attacks”. We began to question all our dependencies and vendors. Who are you, and what are you made of?! We saw outages increase for Azure, AWS, GitHub and Atlassian. And, we finished it off with arguably the GOAT vulnerability: Log4shell. What a crazy f**king year, right?!
It’s now time to turn our attention to the new year and I thought I would crack a tasty beverage and wax prolific on what I see coming for the DevSecops and AppSec communities for 2022. As always, I appreciate your feedback so feel free to hit me up in the comments below or ping me on the socials.
1. “Software Bill of Materials” (SBOM) is everywhere!
Every American we talk to whether they are in venture capital, startups or enterprise is asking us if we can provide SBOM capabilities. Australians are beginning to become aware of the idea as well via our five eyes osmosis. The impetus behind this all are a new set of requirements set down by the Biden administration in 2021 that enforce SBOM standards on orgs trying to sell into US government. My first prediction for 2022 is that SBOM will evolve to become “Application Composition Graph” as the idea of SBOM expands to include the non-source code dependencies in applications. Think AWS Cognito, Cloudflare Workers, API Gateways, Lambda, Azure Functions, Firebase, etc. If you take any of those services out of an application that uses them, that app stops working. If the app can’t live without something, then that’s a primitive dependency. Therefore, these dependencies need to be expressed in the same way that a node or python library does. Like many standards, the people defining the standards often don’t understand how the underlying controls or requirements are enforced. As an example of this the current SBOM standards and formats like CycloneDX only really work with software package files. They will have to evolve to provide SBOM features for cloud infra, SaaS tooling, CI/CD processes and more as these components are just as required as the underlying source code. This new “enhanced” SBOM complexity absolutely screams out for a graph to express those complicated back and forth relationships between dependencies. However, you will always need to provide for it in something easy to undestand for machines so this means that whatever “graph” like representation we use, this new SBOM will have to be able to be represented in JSON or YAML. At SecureStack we have been using an internal description of an application called a WHAM since April 2020. This WHAM stands for “workload hierarchy abstraction model” and is really about understanding how data enters an application and what it touches. For example, the CDN, loadbalancer, webserver, appserver, app and database are all listed in order and their individual dependencies and relationshipos are defined. This is similar to SBOM and makes it easy for us to map to the new SBOM requirements. Checkout my teams thoughts on SBOM here: https://securestack.com/sbom
2. CI/CD Visibility
The theme from 2021 was: how do we modernize the software delivery process because we all might be working from home for a while? The ability to focus on modernization was made possible by the fact that everybody was at home and the company VPN and infrastructure was not always capable of enabling or satisfying the needs of software engineering teams. So this created a forcing function to move to cloud-based SCM like GitHub and Bitbucket as well as cloud-based continuous deployment platforms like CircleCI. Stuck at home, engineering teams had time to finally build out automation that we had been talking about for years, enabled by the ease of the new cloud SCM vendors. At SecureStack, we saw this a lot as legacy enterprise customers suddenly started using Bitbucket Cloud and GitHub because there were too many obstacles to them using their existing legacy SCM solutions. But now, in 2022, these orgs have moved successfully to the cloud and are building their first production-quality continuous delivery models, they need to focus on gaining more visibility into all this new “stuff” so management will continue to give them the green light. And the budgets. Salivating startups seeing new market opportunities will build visibility platforms to compete with native functions from GitHub, Bitbucket, and all the other platforms. Up until now different parts of the #devtools space have been pretty siloed. Different focuses like “code quality”, “code security”, “application performance”, “dev collaboration”, “api functionality” and “developer insights” will come together in explosions of tooling to join existing continuous deployment solutions to create richer ways to define maturity and progress for engineering groups and their managers. All of this brings us to….
3. CI/CD is the new Supply Chain attack target
In 2021 we saw attacks targeting npm libraries like ua-parser-js as well as dependency confusion attacks targeting Microsoft and malicious code found its way into the Linux kernel. This got me thinking about my own continuous deployment pipelines and how we use third-party software in those pipelines. And that got me thinking specifically about GitHub Actions and Bitbucket Pipelines. These two technologies run pieces of automation in your continuous integration and deployment processes and many orgs rely on third-party providers to deliver these stackable pieces of automation. And here’s the thing: These Actions and Pipelines have complete unmitigated access to your source code during the CD processes. During the testing and build phases for all your continuous deployment vendors spin up temporary transient containers to test your code and do “stuff”. Some of that stuff involves security testing or functional testing. There are thousands of these automations out there and many orgs use these functions without really understanding what they are doing. Imagine if someone got access to one of these popular Actions and inserted a single line of code that sent your source code to an S3 bucket. Whoops, your intellectual property just got sent to China! Or maybe it added a line to your source code to use a new dependency that was malicious? There are a million things that a bad guy could do with this super powerful moment in time. Most of the GitHub Actions for example are maintained by small teams of volunteer contributors. How many of them use MFA and/or SSH keys to interact with GitHub? How many of them are using EDR on their laptops to make sure that someone isn’t manipulating files on their local repositories?! It’s really hard to define security standards for a group of people who are volunteering their time. So just like with the NPM dependency shit show, the GitHub Actions and Bitbucket PIpelines and similar are places we need to start looking and thinking about how do we secure these new tools?
4. DevSecOps hype-cycle will hit escape velocity
Every vendor will claim to be a “DevSecOps” solution. In 2022 we will see XDR, EDR, CSPM, and other solution providers start marketing in this space claiming to be the “missing piece of the DevSecOps puzzle”. It will get totally non-sensical over the next year. Tools that have no business in the continuous deployment process, will build GitHub Actions and start advertising how they are an integral part of your continuous deployments. Non-technical managers who are easily swayed by big names will not be able to discern what is legit and what isn’t, which is the whole point of this marketing frenzy. Technical people will be forced to add Actions and Pipelines that just make their deployments even slower and make them start building rogue CI/CD solutions.
5. Software Composition Analysis hits a snag
Traditional software composition analysis (SCA) solutions will stagnate as development teams realize how little value they provide in isolation. This is one reason that Snyk is acquiring startups left, right and center. For example, NPM has had built-in SCA functionality via its npm audit since 2018 and moreover, npm audit messages have been shown by default during every npm action since npm 6. Unfortunately, pretty much every developer and really the whole javascript community ignores these messages every day. Engineers simply ignore these messages, both on their laptops and in their continuous deployment processes.
6. Semgrep will be acquired
Or more correctly, the company behind the amazing Semgrep tool, R2C will be acquired. Semgrep is just too good to not get gobbled up for hundreds of millions of dollars. It probably won’t be Microsoft because they (well, GitHub actually) already bought Semmle in 2019. And it probably won’t be AWS because they keep thinking they can compete with their Code* products and so far they haven’t shown any interest in acquiring in this space. Snyk bought Deepcode in 2020 but I think the bigger blocker here is that Snyk doesn’t target a community, while that’s exactly what Semgrep is all about. So who does that leave? Google? Cloudflare? My pick might seem like an odd one, but I’m gonna say IBM. Or, actually, the new MSP part of IBM that has been spun off on the NYSE: Kyndryl. Kyndryl has cash on hand (via IBM debt) and they desperately want to get into the DevSecOps play as a way to build out both their services business AND their product line.
7. Palo Alto will buy a #devtools startup
Why not? PAN is trying to build an end-to-end platform, so why not throw some code security tooling under the umbrella? There are a bunch of players out there to buy. Aqua already bought up Argon.io so you can mark them off the list but you still have Oxeye, Cycode, Cobalt,
8. Java will become persona non grata
In light of the recent log4shell shit show and its never-ending patching requirements, many in the industry have started saying openly that we need to get rid of Java, permanently. Like, the Godfather and the cannoli permanently. This technology is old, is SLOOOWWW, and has too much attack surface. There is so much XSS, CSRF Advertising a JSESSIONID: cookie is now a liability and the attack traffic you will have to block at your edge has now become one of your teams full-time jobs as they manage traditional firewall and WAF rules to address the never-ending onslaught. Not to mention that we’ve basically forgotten as a culture how to install a JDK or JRE on our laptops which kind of says it all, right? In a post-Java world, just imagine the cost savings in no more WebSphere, JBOSS, or WebLogic, or Liferay licensing! Java was great back in the day, but it’s not worth the hassle now.
9. AWS will give up on its internal Code * services
AWS has a series of software development solutions all starting with Code: CodeStar, CodePipeline, CodeDeploy, CodeBuild, CodeCommit and CodeArtefact. No one uses these tools unless they are clueless or complete AWS fanboys. Don’t get me wrong, we love AWS but AWS can’t be everything to everyone. I know that’s their play, but I can’t help but think of the amount of energy and time they are wasting internally to make all these Code* solutions get traction. The reality is the market is set and other vendors outside of AWS do this whole software development lifecycle stuff much better. Every software engineer (aside from fanboys) understands this, but when is AWS gonna finally admit they can’t do everything?
10. CEOs will start going to jail for hiding data breaches
Australia
11. Everything will become “critical infrastructure”
Australia
Paul McCarty
Founder of SecureStack
DevSecOps evangelist, entrepreneur, father of 3 and snowboarder
Forbes Top 20 Cyber Startups to Watch in 2021!
Mentioned in KuppingerCole's Leadership Compass for Software Supply Chain Security!