Modern software development requires new methods like microservices and containerization, but will this shift in development practices jeopardize software risk management best practices? This is the question at the forefront of my mind as we head into OSCON 2018, the open source convention in Portland, Oregon.
Two sessions I’m particularly excited to attend are RedHat’s Microservicing like a unicorn with Envoy, Istio and Kubernetes and ThoughtWorks’ Building evolutionary architectures. It’s widely accepted that a microservices approach can provide effective building blocks for evolutionary software architectures, but will these efforts come at a cost to software risk and security efforts? I can’t wait to see how these speakers work risk management into their presentations, if at all.
Why Software and Security Risk Management is Important in Open Source Development
Starting new development or modernization projects with open source frameworks makes sense. It reduces the man hours required for development, and therefore the cost of creating a new application. But without proactive software risk management, teams can waste hours in re-work or in scrambling to fix security vulnerabilities after a breach is discovered.
Equifax is a great example. Last year, we wrote that one of the biggest lessons learned from the Struts vulnerabilities exploited in the case of Equifax was that teams need to use software risk scorecards more frequently, and especially when leveraging open source frameworks. Even though the open source community regularly vets and validates the efficacy, quality and security of OSS components, it’s possible that some vulnerabilities slip through the cracks. Are you willing to take that chance?
A software risk scorecard should assess technical risk for complex, multi-tier infrastructures utilizing multiple technologies. By breaking-down each application into defined business functions, scorecards deliver measurable risk scores that can be benchmarked and tracked over time, scan by scan.
A good software risk scorecard will assess potential threats based on software complexity, software size and system vulnerabilities. This information gives development teams opportunity to:
Reducing Software Risk with Microservices
The main thesis of microservices is that it enables teams to change any component of an application when needed. So, theoretically microservices should support application architecture, and therefore software risk, best practices. This is great for modernization and digital transformation mandates but be careful. Teams shouldn’t take microservices as a “get out of jail free card” when it comes to software risk.
Just because you can remove an individual brick that can be replaced, doesn’t mean you can – or should – just yank it out. Doing it right still requires architectural oversight and enforcement. The key is supporting evolutionary change with the right guidelines while being flexible, non-intrusive and non-inhibiting.
Come see us at OSCON 2018!
If you’re interested in learning more about CAST’s approach to software risk management in open source and microservices, come stop by Booth 800. We will have prize giveaways, demos and lots of information about Software Intelligence. We hope to see you there!