The source of all human knowledge (Wikipedia) describes application security as “measures taken to improve the security of an application often by finding, fixing and preventing security vulnerabilities.” AppSec is all about developing software that is as free of vulnerabilities as possible. Compare that to “InfoSec,” which is a broader discipline that includes areas such as network security, endpoint security, and incident response.
In this article, I’ll take a look at the role that AppSec plays on many teams, barriers to its effectiveness, and suggest some considerations for building more secure applications.
Who is on your AppSec team?
Many folks in the InfoSec field come from a background in IT Support, possibly with a background in software development. Suddenly, they’re asked to do application security. Almost all of them will be responsible for operating the scanners and tooling, a job that is basically appliance operation. A large number of them will be encouraged to do pen-testing along with mandates like “run a DAST or IAST against this and give the results to the Test Group, and in your spare time SIEM these app logs please, etc.”
Depending on the organization, they might also do code reviews and training. That works better if the AppSec team has equity and credibility with the developers, and maybe has been staying current with the language and frameworks we are using these days.
The more that AppSec specialists have development skills, the closer they are able to move to the left side of the CI/CD pipeline. They may join design meetings, participate in kickoff sessions, and sprint planning. They may even take on some of the roles of an engineering manager or architect working on the design ramifications of the security scans. Less common is to see them standing in front of the stakeholders with any regularity, arguing that a given vulnerability takes priority over any of the requirements that are driving the product that they are scanning.
What are the barriers to effective AppSec?
AppSec effectiveness can suffer under several conditions:
- It happens too far on the right side of the CI/CD pipeline
- Driven by InfoSec types rather than developer types
- Doesn’t effectively treat the root causes but rather the symptoms
- We are having the wrong people doing the reviews (probably at nowhere near the speed and efficiency needed for the pipeline).
The fundamental issue is that we are using traditional, legacy software development style paradigms on a DevOps-CI/CD pipeline with CI/CD type coding styles and methods. Right side AppSec assumes a more static and stable endpoint which is completely against the beauty of devops-CI/CD (change early, change often, take your best shot and throw the leftovers on the backlog…).
A better approach: Smart software development
A better approach for AppSec is what I might call “encourage high quality software development.” I have yet to meet a developer that prides themselves on writing crappy software. Every single one has wanted to harden their code, hopefully in an elegant way, and in a way that doesn’t break any existing contracts or introduce brittleness. And that’s not just with security issues, but the entire spectrum of quality.
I have frequently seen developers be given a problem (the specifications of which may change soon after we give it to them…but that is probably a different missive). They think about it and then start to code up a rough solution that generally solves that problem. Depending on how good they are, how much time we have given them and how much support they have, they improve and optimize that initial solution. Wash, rinse, repeat…until we start another feature or sprint or whatever.
That is where application security wants to happen: with the developer, by the developer, all the way over on the left end of the pipeline. It isn’t necessary for an AppSec tool to be embedded in their IDE, possibly breaking their train of thought as they are working on framing a solution. Simply allow developers to reach a good stopping point and then scan their code with a SAST/SCA tool prior to committing their code back into the repository. This concept is similar to when a developer would compile C/C++ looking for errors, run SQL statements and verify whether the joins worked, or refresh a webpage check the rendering.
The SAST/SCA tool shows developers the issues that need to be “optimized” out prior to a merge back to the main branch. The code and problem requirements are still fresh in the mind of the developer. But, they’re not so far into the pipeline that issues surface in the swift water rapids on the backside of the repo headed into the Test group — and the expensive zones to the right of the CI/CD pipeline. Developers know and are familiar with the code and context and have the best view on what and where to fix a given thing.
What about scanning later in the pipeline, after code is committed to the repository? At that point, issues present as enhancement requests or bug fixes that get thrown into the queue to fight for a position and priority in some future sprint. They may also become a seed artifact for team members on the right side of the pipeline (but that’s yet another topic).
Developing secure developers
One issue with all of my great observations is the developer’s knowledge level. I hear that often. If developers could learn how to NOT build vulnerable code in the first place, we wouldn’t be having this conversation. The act of software development presents a teachable moment that needs to be leveraged. When we help the developers scan for vulnerabilities, we also need to give them clues on how to win the “fixing game” (insert your favorite method here – gamification, external training sites, a wiki/intranet, golden neutralizers or patterns, beer…whatever).
I think the teachable moment occurs outside of the IDE when developers are in a “review and improve” frame of mind rather than a puzzle-solving place. There is also probably an additional argument for this happen outside of the IDE to make it a non-blocking/non-slowing maneuver. If we must skimp on “testing” then we can do these scans later and charge it to technical debt.
What should AppSec look like?
There is a function that wants to happen by AppSec teams, but it runs at a different tempo from development. AppSec is more of a layered security function, probably closer in DNA to the Test Group. It generates deliverables that look a lot like enhancement requests or bug tickets and enter the workflow through those processes. AppSec specialists may have a teaching and evangelizing role but it probably will be limited by timing and by not having enough or fresh enough coding scars on their backs. The security front line in this case is the developer building quality code. And, in the vein of “security is everyone’s job,” their success will depend on how much we help them by giving them time to work, training, and knowledge; and by working together to produce a quality product.
I hold these truths to be self-evident, but I think they are easier for me to see because of my experience with Kiuwan’s solutions for SAST, SCA, and software quality scanning. I spend a lot of time scanning code with Kiuwan – from inside the IDE, to the repo pull request, to various points to the right in the build and release process.
That position alongside the developers and in the pipeline gives me an opportunity to watch the system work and hear the about the pain and recommendations, rummage around my integration “toolbox” and come back with a refactored Kiuwan that hopefully speaks to those pain points and recommendations. If you want to try out first-hand a SAST and an SCA tool, contact our sales team today to request a trial of Kiuwan.
Would you like to know more about implementing SAST and SCA in your organization? Get in touch with our Kiuwan team! We love to talk about security.