Press Release
Last Updated on January 8, 2024
If you’re thinking of putting some initial security steps in place within your DevOps pipeline, should you start with an existing application? Or with a new application where you’re starting from scratch.
André Keartland, Solutions Architect at Netsurit, advocates the greenfield approach.
“I find it’s easier when you can start on a blank sheet of paper,” advises André. “If you’re savvy enough and you’ve got the drive and the budget, you can build in security from the word go.”
But beware those “classic” prototyping and proof of concept (PoC) scenarios where a “minimal viable product” (MVP) with no security ends up being pushed forward into production in the interest of time-to-value. Even if the PoC gets reworked, developers are notorious for pasting chunks of insecure PoC code into the production code base, which often isn’t detected.
“I wish I had $10 for every one of those I’ve seen,” jokes André. “The road to Hell is built one shortcut at a time.”
Start with the basics
After you’ve chosen the right project for your initial DevSecOps effort, then what? Do you implement code scanning? Chose an automation server? Start integrating security stories into agile sprints?
“Start with the basics,” André recommends. “Always go from the simplest to the most complex. So, to get going, sort out some of the security basics in your environment. Even if you’re not formally doing DevSecOps as a program or standard within your organization, start looking at things like protecting your Dev environments.”
Often developers are the “total opposite” of how you want users to behave around security. They tend to have Admin rights on their machines and they’re keen to install all sorts of software they find on the internet. They are known to indulge in incredibly risky behavior that needs to be contained.
For example, André suggests giving developers separate virtual machines with different permissions for “playing around” versus formal coding. Leveraging common security controls like monitoring and endpoint detection/response (XDR) for developers as per other users is also recommended.
Batten down test environments
Test environments are also common sources of vulnerabilities, especially when they’re not properly isolated from production. Test is often viewed as a playground where security can be lax. This makes it the perfect entry point and springboard for threat actors looking to infiltrate your precious code.
Another common problem is copying production data onto test and dev systems to “test with real data.” If these insecure systems are then compromised, the result can be a major compliance violation and/or an embarrassing announcement for impacted customers and other stakeholders.
Why not start with an existing app?
Driving DevSecOps into an existing app can be extremely difficult because it forces you to deal with whatever “legacy” you inherited from whenever the app was developed, including the shortcuts that may have been taken with security. The original code could be written in COBOL, for instance. Now you’re trying to make it run in the cloud, so there are probably many security gaps and shortcomings.
Factoring security in alongside so many other code change issues is likely to be highly complex, and not the best scenario for starting things up and working out the kinks.
What’s next?
For more guidance on this topic, listen to Episode 114 of The Virtual CISO Podcast with guest André Keartland from Netsurit.
Free OWASP ASVS Testing Guide
If you are just learning about OWASP’s testing standard or are considering the best way to prove the security of an application, this guide is meant for you!
