Organizations will see big wins from applying security controls early in the development life cycle.

Yvonne Dickinson, Director of Security, Owlet Baby Care

February 28, 2022

4 Min Read
The phrase "Application Security" on a monitor
Source: Artur Szczybylo via Alamy Stock Photo

When I was a young developer, fresh out of college, application security was not a thing. My degree is in computer science, and I don't even recall a single application security-related course. As a developer, it was hard for me to understand how the work I did could have an impact on security.

Back then, I associated security with mandatory training to spot phishing, network-layer defenses, a roadblock to delivering my requirements in development on time, and a bunch of bureaucratic policies that made no logical sense to me. I kind of wanted nothing to do with security. Until I saw it. What is it? It was the flaw in my code that allowed me to manipulate outcomes. Thus started my passion for application security — and a new career path that I would grow to love more every day.

In my career, I've built multiple ground-floor application security programs. The first one took trial and error, but I ultimately got there. The subsequent programs got better and better. What's my secret? Knowing my audience!

When you create an application security program, it's not a dictatorship, it's a partnership. It's also important to note that in order to succeed in application security, you need to be bilingual. You need to speak developer and you need to speak security.

I maintain that the two most fundamental success criteria of development are:

  1. Functionalize business requirements

  2. Meet deadlines on time

Shift Left
Knowing those top development success criteria, how do we not negatively impact them?

The answer: shift-left security, the application of security controls as early in the software development life cycle (SDLC) as possible. When you discover a code flaw during the development stage of the SDLC — not every flaw is a vulnerability, but every vulnerability is a flaw — the time, money, and effort it takes to remediate is exponentially less than if it were discovered as a vulnerability in production … or worse, exploited.

There are many great static application security testing (SAST) solutions out there that can analyze code as developers are coding and offer remediation in real time. Don't want to use a SAST plug-in to your IDE? Fine, integrate SAST to your automated pipeline. Automate the failing of builds that don't pass a security policy. If your SAST solution finds a critical flaw or vulnerability, don't allow the pull-request to merge to master. Your developers will appreciate your interjection earlier on than if you decided to pull the plug and force an emergency remediation effort after a product/software/firmware has been deployed to production.

Let's address the Log4j vulnerability. You can keep shift-left security in mind when dealing with third-party dependencies too. Software composition analysis (SCA) scans your software and compiles a bill of materials (BOM), listing the components of your application and the versions being used. Many robust binary SAST scanners will have SCA as an option too. Do both! Know what you're dealing with in your environment. When the next Log4j zero-day occurs, how nice would it be to quickly search that particular dependency and version so that you can determine the impact and create a plan for the next steps?

Let's take a step back from the technology. Remember when I said the secret successfully creating application security programs was knowing your audience? Well, developers are logical thinkers. They will be more inclined to be on board with your security program if you start with the "why" and give them the opportunity to buy in or voice their concerns because what you do needs to make sense to them. Every security technology I onboard, I run a proof of concept with the development group that will be impacted. Every policy I write, I enlist representatives from development to approve. You'll be surprised how far the power of partnership takes you.

Other things you can proactively do to boost shift-left security in the SDLC:

  1. Create standards for application security and communicate them: Give developers expectations for security success.

  2. Provide courses for secure coding and incentives for developers that go above and beyond: Reward your security champions! You need them!

  3. Make friends with your project managers and brief them on security requirements so they know to reach out to you when new projects spin up: You don't want to be the last one invited to the party.

While it's also important to be prepared to be reactive when it comes to security, the big wins come from that shift-left security approach and the positive culture you create with it.

About the Author(s)

Yvonne Dickinson

Director of Security, Owlet Baby Care

Yvonne Dickinson is currently the Director of Security for a global and publicly traded company. Her depth of expertise resides within application and cloud security, although she is a generalist across the other security domains. Yvonne is extremely passionate about advocating for women in STEM fields and strives to make an impact where she can. Although her official title is Security Director, that job is secondary to her primary role as CMO — Chief Mom Officer — to her family. As a technical leader, she strives to find balance in her work and her home so she can succeed at both her jobs, and she empowers her team to do the same.

Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

You May Also Like

More Insights