With the need to produce innovative software faster than ever, and cyberattacks not slowing down, it’s no surprise that, for projects large and small, ensuring the security of your code at every step is key. But if software engineers want to meet these everyday demands with success, it’s important to understand how different security scanning types fit in throughout the development process, and how the needs of your team might impact scans.
In my role as a Principal Solutions Architect here at Veracode, one of the main benefits is that I’m able to help customers do just that. One recent project in particular involved working with Stephanie Visser, a Software Engineer at Microsoft, to help a large manufacturing customer implement Veracode into their development process. The customer was undergoing a digital transformation at their factories and was missing those critical security scans to cover their code at the developer layer.
As new Veracode users, Stephanie and her team spent quite a bit of time with me and other members of the team figuring out the best approach for implementing our testing tools. Here’s how that project unfolded to improve productivity and boost quality for the customer.
Setting the scene with user stories
But the customer also wanted to use Veracode’s scanning solutions to improve the level of security in multiple stages of their software development lifecycle. That would, in turn, help them move security to the left so that it’s integrated sooner in the coding process, helping them catch critical issues faster, saving the organization time and money.
We know there’s no one-size-fits-all when it comes to application security programs, and so Stephanie’s team first began to lay out the most relevant user stories. This helped them better understand which scan types fit best at certain stages of the development process:
Evaluating the user stories with paired scenarios, scan types, and frequency not only clarified where they needed to integrate critical Veracode scans but also helped them understand when these scans need to run for maximum efficiency.
My code, our code, production code
“My Code, Our Code, Production Code” is a visual representation of why you can’t treat security scans as one-and-done, highlighting where these critical tests should take place in the software development lifecycle. For example, in the Our Code phase of the process, which includes building, unit tests, and integration tests, using Static Analysis, Software Composition Analysis, and Interactive Analysis gives you better coverage on both proprietary and open source code.
Stephanie’s team leaned on a similar roadmap that fit their needs. They began by enabling developers with Veracode IDE Scan (formerly Greenlight) so that they could hit the ground running finding and fixing security flaws through real-time static analysis of the source code as they developed software.
Pipeline Scan was also an important piece of their puzzle; while IDE Scan is a solid first step for the development process, Veracode Pipeline Scan enabled them to check for flaws that might not have been recognized when scanning individual files. Sandbox scans and policy-related scans also made the cut, as Stephanie and the team wanted a way to ensure that code is as compliant as possible when they measure it against the customer’s policy.
Although they faced scalable hurdles along the way, the project solidified for Stephanie just how important it is to create code with security in mind and to lean on scanning tools that integrate easily into your existing software development processes.
To read Stephanie’s full story on implementing Veracode, please visit our Community.