In recent months, as I’ve worked with more and more prospects and customers, I’ve started to see an interesting trend: As more agile dev teams become responsible for their own security posture, they are relying on the operations team to “plug an AppSec tool” into their CI/CD pipeline to resolve their AppSec. While I agree with the sentiment that security needs to be embedded in the build process, I am always surprised that a “tool integrated into a CI/CD pipeline” is as far as the planning typically goes. Saying that, I was told by one of my best mentors that consistency should never be a surprise.

When I ask these same teams, “once you plug a tool into your CI/CD and you get results, what are your next steps?” I am mainly met with little to no response. Basically, these teams are going from ignorance of their application security state, to knowledge of security-related defects in their code, to security negligence by not acting to address these risky defects.

I have even seen AppSec programs that check all the boxes – they have solid, prioritized app inventories; executive sponsorship; integrations; remediation and mitigation points; policy management; multiple testing techniques; and centralized reporting – yet some agile teams are stepping in and taking a “tool approach” that only focuses on scanning instead. This is not only short-sighted, but also reveals a knowledge gap surrounding what it takes to make an AppSec program successful as security hands the program to individual agile dev teams. When I check-in on these security teams, inevitably all the early momentum they leveraged to overcome cultural hurdles and foster a “security is everyone’s responsibility” mentality has come to a halt. This includes the aspirational goals around passing policy and establishing remediation checkpoints. This is not due to development doing the scanning directly (they should do this), but rather governance of the larger AppSec outcomes fading away. Ops seems more interested in how many scans they can do per day … with no further outcome.

Don’t fall into this trap. You can’t scan your way to secure code. Security teams still need to be a part of the security picture as scanning occurs in the CI/CD pipeline. Here are three key aspects of application security “beyond scanning” that will produce real risk reduction from your efforts:

Secure coding education:

The easiest flaw to fix is the one that is never introduced in the first place. However, most developers don’t have secure coding skills. While it is great to have a scanner built into the CI/CD pipeline, it is just as important now to shift testing “left.” With tools like Veracode’s Greenlight, developers can fix flaws in real time in their IDE while building their applications. In turn, developers learn as they code and reduce the number of flaws introduced over time. In addition, to help drive secure coding education, Veracode provides a number of options for sharing best practices, including instructor-led trainings such as lunch and learns, eLearning on AppSec, and developer workshops on secure coding.

Fixing what you find:

Ultimately, your AppSec program is not effective if you’re not fixing what you find. You can scan every piece of code you write, but without adequate training and guidance, you will not create more secure code. In fact, you will delay developer timelines and still produce vulnerable code. Enabling developers with both a scanning tool and remediation and mitigation guidance is key. At Veracode, we conduct over 5,000 consultation calls a year with development teams, guiding them through fixing flaws they have never had to address before. And we’ve found that after only one to two of these calls, developers’ secure coding know-how improves dramatically.

In addition, your AppSec program also needs to be set up to enable remediation guidance.

For instance, every scan completed should be assessed against a policy — not a policy that changes how you scan or what is discovered, but rather a filter of the results to see if you passed or failed based on the parameters you set for risk tolerance. This policy should also include: how often does a team need to scan, how long do they have to fix certain flaws based on severity/criticality, and what scanning techniques must be used. In addition, you need remediation time built in between scans. Just scanning multiple times a day and pulling results into a tracking system is not useful if no one has the bandwidth to fix anything. You are better off setting a realistic scanning schedule (once a day) so developers have time to fix what they find. You can increase scan frequency as you become more secure and are passing policy on a regular basis.

Scaling:

Can your security team help your development teams fix all the flaws their scans are finding? If you have multiple development teams working in different environments, this can be a nearly impossible task for one central security team. In addition, developers are naturally curious, so just giving them scan results without explaining the underlying technology finding the flaws will lead to push back.

Considering the skills shortage, engaging outside AppSec expertise goes a long way, both to establish your program’s goals and roadmap and keep it on track, and to guide you through fixing the flaws you find. We aren’t suggesting you replace your security team with consultants, but rather that you complement it with specialized AppSec expertise.

We’ve seen the difference this support makes: Veracode customers who work with our Security Program Managers grow their application coverage by 25 percent each year, decrease their time to deployment, and demonstrate better vulnerability detection and remediation metrics. In addition, Veracode has a fully staffed Advanced Integration Team. They work with global companies to help build out scanning in complex CI/CD environments that can vary by teams and regions. It is rare we see a one-and-done simple set-up that enables a full organization. Ultimately, our experienced Security Program Managers help you define the goals of your program, onboard and answer questions about Veracode products, and work with your teams to ensure that your program stays on track and continues to mature.

Learn more

Don’t let ignorance become negligence. Get details on what a mature, effective AppSec program looks like in our Everything You Need to Know About Maturing Your AppSec Program guide

Pejman Pourmousa is Vice President of Services at Veracode, where he is responsible for the successful adoption of Veracode’s solutions by its customers. This includes program management, customer success, security consulting, manual penetration testing, and customer support. In the last seven years, he has built cohesive teams that help cutomers develop, deploy, and mature their AppSec programs. Pejman has spent the entirety of his career in the area of services management and delivery, specifically around compliance, risk, and security. Prior to Veracode, he was a Manager of Client Services at Integrity Interactive (acquired by SAI Global), where he led the team responsible for the delivery of compliance and risk solutions across SAI Global’s client base. Pejman holds a bachelor's degree in Business, History, and Secondary Education from Brandeis University in Waltham, Mass. 

Love to learn about Application Security?

Get all the latest news, tips and articles delivered right to your inbox.

 


 

 

contact menu