The software community is on the brink of accelerating changes as DevOps practices, agile development methodologies and AI gradually, but surely, phase out legacy approaches. But while this is a fantastic development on the one hand, it’s also perplexing on the other. There’s no doubt that enterprises can’t competently respond to the need for greater speed and the rise in complexity of application categories with single-tiered systems that ruled supreme for years.
Yet, tighter deadlines mean that DevOps teams are often pressured to go into production with applications dotted with defects, which can develop into tomorrow’s security issues and lead to costly security breaches. To fight hackers’ deceptive sophistication and increasing agility, companies must install an application security (AppSec) testing framework that will remediate vulnerabilities without depleting time and development resources. If your organization hasn’t yet implemented one, consider adopting the following list of best practices to keep hackers at bay.
1. Embed AppSec early on for best results. If you postpone testing until the closing phase of the development process, your team will end up doing more work than initially planned. Bugs will be difficult to detect and burgeon beyond patch-up. Plus, it’s an expensive habit — last-minute code changes are always costlier than those made earlier in the development process. You’d also exhaust your team as it rummages through code to record and repair defects and other vulnerabilities.
2. Develop good manual testing practices. While automation is crucial to DevSecOps, manual testing should still be a mandatory component of your workflow, because people can detect a range of bugs that algorithms cannot. Automated tools lack the creative sophistication to venture outside testing rudimentary vulnerabilities. Scanning instruments, however good, routinely fail at identifying authentication and authorization bugs. Only real people can step into the hackers’ shoes and inspect all assets to check if exploitation is likely.
3. Prioritize business-critical applications. Hackers are usually motivated by acquiring the target’s “crown jewels,” because their value is directly related to the sum of money a company will obtain in a given day; if breached, the business may be compromised in other ways. If you’re wondering which assets should be next for application security testing, always choose the components that are most vital to the company’s bottom line.
4. Don’t forget third-party code security. With a rise in applications created out of house, collected off the shelf or via open source, companies should scrutinize these components to the same degree they inspect their own code. This is especially relevant since many applications considered internal are, in fact, composed of third-party libraries and assets. What’s more, huge chunks of third-party software don’t meet IT security standards, meaning they’re packed with vulnerabilities and can be exploited easily.
5. Keep a lid on automation. Although automated tools are valuable time savers, there’s a threshold to how much benefit they can offer. A number of other tools exist that are better suited for identifying different types of vulnerabilities: Static analysis, for example, can detect and fix simple flaws whether they’re found in-house or off shelf; dynamic analysis is good for securing and monitoring all kinds of web applications, including the ones you didn’t know existed.
6. Create a policy framework. Draw up a list of criteria based on risk factors so your team knows which flaws need immediate attention and which can be put on hold. Also consider creating a guidance outline for remediation activities, which will form a standardized protocol and reduce vulnerability monitoring on an ad-hoc basis. The framework should also define your scan frequency, which can be revisited as your code becomes less vulnerable.
7. Establish metrics. A good system of measurement should be treated as a scorecard of your exploitation management efforts. It reveals whether you’re detecting fewer bugs over time and if it’s taking more or less time to identify them. To get a full picture of your application security, you should periodically check your asset coverage and other performance criteria: How much surface area is covered by automation versus manual testing? What’s your vulnerability acceptance? Meaningful improvement is unlikely without properly assessing the status quo.
8. Don’t put all eggs in one basket. In other words, diversify your AppSec testing methods. There’s no magic solution that fits every scenario. Acting like there is would be like hiring a detective who interviews only one source; you need different testing methods to cover all angles. Every testing tool, whether it’s penetration testing, software composition analysis or fuzzing, has its own unique purpose — together they work in sync, like a meal full of different spices with each spice bringing out its own aromatic flavor.
9. Assign your team’s security guru. Another good way to bolster your DevSecOps is to cultivate a security expert on your team. Their job is to act as the team’s guide when it runs into trouble. Implanting a security pro who will answer questions and solve problems on the go will decrease the number of logjams and free up time so your team can work on creative tasks that generate long-term value.
Integrating AppSec successfully into DevOps can be a challenge for enterprises as faster and more flexible methodologies demand greater complexity and shorter deadlines. But the urgency of going to production without proper AppSec testing practices will only lead to a buildup of defects that will cost you more in the long run. To avoid finding yourself in this predicament, you’ll need to install the right tools, implement appropriate practices and make some changes in your organizational culture. Otherwise, your clients will end up with Swiss-cheese code, and that’s no one’s idea of a good business strategy.
