PROBABLY AN INTRACTABLE PROBLEM
In the old days, security teams were all about protecting the code, written ‘in house’, that powered the features of their software. The dawn of SAST. We called it appsec.
Along came open source, and security teams needed to think about code written by other people that powered the features of their software. The dawn of SCA.
At the same time, along came the cloud, and security teams had to think about the code that configured their cloud hosting environments. The dawn of IaC security. We still called it appsec but started to call it devsecops as well.
Not everyone deploys software to the cloud. IoT devices, missile control systems and there are still many people running their own data centers. The list goes on. You can’t really call it cloud native security because it would miss a massive amount of the worlds software, that still has many of the same set of problems as today's cloud native world.
I think DevSecOps is the only term that covers enough of the worlds developers and should replace appsec. Note : I know not everyone does devops but nothing will be perfect and it's closer than appsec.
The technology coverage to check for ‘all the things’ in DevSecOps is woefully insufficient.
SCA doesn’t and SAST tools have very limited features, if at all, to check for the appropriate security use of the ever increasingly complex and ever increasing array of frameworks, APIs and SDKs. They focus on checking for vulnerability patterns and not conformance. In a world of increasingly declarative programming that's a big miss. Look at the programmable web directory and you will understand the size of that problem.
That's 24,701 public API’s, 19,455 SDKs, 562 frameworks, 7,995 mashups. They only list 1,705 libraries and there are certainly over a million NPM packages alone.
I have no practical idea of how to solve this problem, but I do know it will only get bigger as time moves on.
Yes, we have a newsletter at www.crashoverride.com