3 Ways Product Engineering Teams can better manage Security Vulnerabilities

DevSecOps, tooling, Vulnerability Correlation
Puru Naidu | September 18, 2018
find early, fix early


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 processes 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.


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 focus on critical or segmented parts of the application. For example, lightweight scan policies (smoke/ sanity) can be configured to run on nightly builds where as more aggressive scan policies can be scheduled for weekly builds.


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 are 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.


Automating the vulnerability logging process is critical in sending the right information at the right time. The time taken for a critical 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.

Where Orchestron fits in?

Orchestron has been designed to enable product engineering teams to manage vulnerabilities effectively within the time usually available within release cycles.

Find Early : Orchestron integrates with most of the popular open source and commercial SAST and SCA tools view of security bugs within Code-at-Rest. These scans can be triggered using the CI plugins provided by most platforms as part of the daily build. Orchestron’s integration with Jenkins allows these scan results to correlated, de-duplicated and presented on a single pane of glass. Application Security teams can also perform parameterised DAST scans using the Orchestron Client component as part of weekly builds within Integration, Staging or Pre-Prod environments.

Fix Early : With Orchestron’s integration with bug trackers such as JIRA and GitHub, developers now have faster and contextual access to security vulnerabilities. Functional and security defects can be routed within the same pipe, enabling release managers to effectively take a GO or a NO-GO call.

Learn More