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:
- Functionalize business requirements
- 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:
- Create standards for application security and communicate them: Give developers expectations for security success.
- Provide courses for secure coding and incentives for developers that go above and beyond: Reward your security champions! You need them!
- 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.
Source: www.darkreading.com