Published on
The vast majority of application security teams are under resourced. The ideal is that application security teams will scale with development teams, but this rarely happens. Given this disadvantage, how can you make your applications safe?
When you have limited resources, the only way application security scales is to shift security responsibility back to developers. Even given infinite resources, developers should ultimately own this security responsibility.
Just like with any other bug found in their code, the development teams who write the code should also be responsible for fixing and maintaining security issues. The same principle applies regardless of how many resources you have.
Keep searching for that impossible-to-find application security engineer, of course. It's an important role. But put security responsibility on your developers, too.
How do you shift responsibility back to the developers? There are four main ways, and we cover them below. Plus, we offer two bonus tips to truly elevate your application security at the developer level.
Develop & Enforce Secure Coding Standards
The first step is to create rules for developers to follow. This makes it easier for developers to take responsibility for security. Secure coding standards should spell out what must be done and what must never be done in the languages your development teams use.
For example, in Node you should never use the potentially dangerous functions Eval(), setInterval(), or setTimeout().
There are several free resources for creating Secure Coding Standards including Open Web Application Security Project (OWASP) and US Computer Emergency Readiness Team (CERT).
Your secure coding standards should also include:
- policies for acceptable open source libraries to use
- the process to gain approval for adding libraries to the list
- a process for ensuring that those libraries are monitored and updated in a timely manner
Vulnerabilities that live in open source code become public knowledge. Attackers leverage those vulnerabilities quickly once they become public.
Putting secure coding standards in writing and distributing them to your development teams is a great first step. However, without holding the team accountable, it’s unlikely that the standards will be fully followed.
The standards should be enforced by writing automated tests on all code before being merged with master, using scanning tools like Parasoft, and doing manual code reviews.
If developers are not held accountable, they will not follow secure coding standards.
Implement Secure Development Training
If you are going to shift the responsibility to developers, you need to give them the resources to be successful. How do you expect a developer to protect against an XML External Entity (XXE) vulnerability if they don’t even know what it is?
Arm developers with the tools they need to be able to stop vulnerabilities at the earliest stage in the Software Development Lifecycle (SDLC).
Ensure the training is hands-on and engaging so it is as effective as possible. Developers generally do not want to be forced to take training, but if the training is interesting and leverages their problem-solving skills it will be more effective.
The most effective training has developers actually write secure code, not just learn about it.
Develop Security Requirements
If there is no time dedicated to thinking about security, no one will think about it. As part of the planning process for any new feature there should be time set aside to discuss and develop security requirements. Without thinking through the use and abuse cases and identifying how to stop them, functionality will be built without security in mind.
This omission make things more difficult and expensive to fix later. Some areas to focus on include authentication, access controls, and encryption. All of these have implementation requirements that need to be considered and require planning to incorporate successful security measures.
When you develop your security requirements, be sure to consider confidentiality, integrity, and availability for all data and systems. The National Institute of Standards and Technology (NIST) offers guidelines for how to develop security requirements.
Deploy and Enforce Use of Security Tools
Deploy both static and dynamic analysis tools to help find vulnerabilities. These automated tools add minimal overhead to your development process.
There are many tools that can be used, including Parasoft. These tools should always be run before merging code to master and pushing to production.
Developers should be required to triage issues themselves before merging code, as this helps developers take responsibility for their code. Running dynamic and static tools early and often in the development process helps mitigate costs by keeping the work with the developer who is most familiar with the code.
In order to enforce usage, the tools should be integrated into the Continuous Integration/Continuous Deployment (CI/CD) process. Putting technical controls in place to enforce usage will help ensure compliance.
Bonus Tip 1: Create Security Champions
Many companies have success developing some developers on each team into "Security Champions." This works best if it is voluntary process rather than forcing people into that title.
Being a Security Champion means these developers take on additional responsibility. They are the ones who think about security, ensure that standards are up to date and enforced, research new security requirements that may be needed, and evaluate security tools.
Security Champions are the developers who will think about security when others do not. The success of security champions depends on the size of the team and the culture of the company. It is not worth forcing a security champions program if it will not work in your organization. If you force it then it could have negative effects such as security functions or requirements falling through the cracks.
Smaller companies earlier in their life cycles typically have more success with Security Champions because there is less of a culture change. Having a Security Champion from the start will make it easier to scale as the team grows.
Most organizations have developers that would be interested in doing this, so it is worth the effort to find them and officially recognize their interest.
Bonus Tip 2: Defense in Depth
There are other things that should be done around the Secure Software Development Lifecycle that can help reduce the risk of vulnerabilities in your applications and don't require significant resources.
Additional security controls include adding logging, setting up a Web Application Firewall (WAF) or Runtime Application Self-Protection (RASP), isolating environments (development/production and critical data/non-critical data), and monitoring for unusual behavior.
With limited resources, adding additional risk reduction without adding people is important. WAF and RASPs can be expensive, but they can be implemented without application security engineers.
Final Thoughts
Shifting responsibility to developers is the key to success, especially when your organization has limited resources. Independent of your available resources, developers should ultimately be responsible for the security of their code.
The best place to start is by ensuring that you develop and enforce Secure Coding Standards, implement Secure Development Training, develop Security Requirements, and deploy and enforce usage of Security Tools. You might also want to develop Security Champions and add Defense in Depth.
The earlier you shift the responsibility to developers, the more scalable your application security program will be.
It also helps to get buy-in from your engineering teams. If you don't have your CTO on board with your application security plans, your battle just got harder -- even if the mandate comes from the CEO.
Putting in place these minimal technologies and processes will help speed up development with fewer vulnerabilities to fix later in the SDLC where it is more expensive and time-consuming to address.
Getting developers on board with security ownership greatly improves your applications.
