Since moving away from waterfall method, engineering teams now have a mandate to look at security in the same light and sustained frequency compared to functionality, performance and other parameters. Equipping them with the right tools and process can lead to a better and more secure product delivery . Here are three major ways to empower engineering teams with certain skills and strategies, that improves the security of applications in a self-sustained manner.
LEVERAGE CONTINUOUS INTEGRATION (CI)
The amount of time, cost, and hassle of vulnerability remediation increases as the product release date gets closer and worse during the production stage. According to the Software Defect Reduction Top 10 List, by Barry Bohem, finding and fixing a bug after delivery is 100 times more expensive than during the design phase. To minimize these factors, one solution is to shift some aspects of security testing to the left (as in upstream towards development). You can do so by empowering the engineering teams with skills and tools that enable them to include certain security checks as part of their business-as-usual-jobs.
One of the most practical and scalable ways to do this is to leverage your continuous integration services such as Jenkins or TravisCI. For example, most engineering teams use Secure Code Analysis platforms (SAST) to perform security code checks. Plugging in SAST as part of the application’s routine cron-jobs through CI is very valuable in unearthing potential vulnerabilities right within development. This can be extended to run-time security (DAST) platforms as well. These tests can be run using specific scan policies that focuses on critical or segmented parts of the application. For example, light weight scan policies (smoke/ sanity) can be configured to run on nightly builds where as more aggressive scan policies can be scheduled for weekly builds.
USING SECURITY 'EXPLOITS as CODE'
As per the WhiteHat Application Security Statistics Report, it takes an average of 174 days to fix DAST vulnerabilities, and 113 days to fix SAST vulnerabilities. In most cases, a significant amount of a developer’s time (during security remediation) is spent on recreating security exploits. Critical exploits found via manual pen-testing is usually forwarded to the engineering team via manual PDF reports for a remediation with limited information specifically around the “WHATs” rather than the "HOWs".
When such exploits are written as "exploit automation scripts" (using frameworks like Selenium) engineering teams can recreate scenarios and have a better understanding on the mechanics of the vulnerability. These scripts can also be used to validate fixes thereby creating a regression of sorts for security test cases and can be run against every build to validate remediations and resurfacing of previously fixed vulnerabilities. This not only increases efficiency for fixing critical bugs but also minimizes the back-and-forth interactions between teams for validation of these exploits.
INCREASE VISIBILITY OF VULNERABILITIES WITHIN THE PIPE
Automating the vulnerability logging process is crtical in sending the right information at the right time. The time taken for a crtical vulnerability to reach the developer through automation, as opposed to manual means makes a ton of a difference - especially in agile environments. By automatically getting security bugs within the defect-tracking ecosystem, you can essentially reduce the back-and-forth between teams. This not only saves time by eliminating unnecessary clerical work, it also sheds the needed light on security bugs in the same seriousness as functional bugs. In addition, the integration of tickets to bug-tracking platforms gives the product management team a higher visibility of the security landscape.
The depth of information gives engineers the necessary information to effectively fix the bugs, while eliminating the unnecessary information (noise) that usually comes with it. Necessary information includes the details such as where & how the bug was found but should be devoid of redundant/rhetorical "noise" such as met-data that DAST/SAST platforms usually give out. This eliminates the need for engineers to dig through data to find the right information, thereby saving time and increasing efficiency.
