Top 6 Application Security Must Dos with Limited Resources

The vast majority of application security teams are under resourced, if resourced at all. Application security (AppSec) teams should scale with development teams, but this rarely happens. So, given this disadvantage, how can you make your applications safe and be effective with application security?

The only way application security scales given limited resources is shifting responsibility back to the developers. Developers should ultimately own the responsibility anyway even given infinite resources — it is their code that they wrote and they should ensure there are no vulnerabilities in the same way they would with other bugs. Even with no resources, shift responsibility to developers as soon as possible even while waiting for that impossible-to-find application security engineer. The longer you wait the harder it will be to get your head above water.

How do you shift responsibility back to the developers? There are four main ways:

  • Develop & Enforce Secure Coding Standards
  • Implement Secure Development Training
  • Develop Security Requirements
  • Deploy and Enforce Usage of Security Tools

And here are two additional ways (Bonus):

  • Security Champions
  • Defense in Depth

Develop & Enforce Secure Coding Standards

For example, in Node, do not 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).

The Secure Coding Standards should also include:

  1. the policy of what open source libraries to use
  2. the process to gain approval for adding libraries to the list
  3. 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 and attackers use them very soon after they are public.

Putting Secure Coding Standards in writing and distributing them to the team is a great first step. However, without holding the team accountable, it’s unlikely that the standards will ever be fully followed. The standards can be enforced by writing automated tests on all code before being merged with master, adding modules to tools like Sonarqube (community edition available) or other code scanners, and/or doing manual code reviews. If developers are not held accountable they will not follow secure coding standards.

Implement Secure Development Training

Develop Security Requirements

Deploy and Enforce Usage of Security Tools

Developers should be required to triage the issues 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 keep cost low by keeping the work with the developer who is most familiar with the code. In order to enforce usage of the tools, they 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: Security Champions

Security Champions are the developers that 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 it to force security champions if it will not work in your organization. If you force it then it could have negative effects such as security functions/requirements falling through the cracks.

Companies that are smaller and are earlier in their lifecycles 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 do have developers that would be interested in doing this so it is worth exploring.

Bonus: Defense in Depth

Conclusion

The earlier you can shift the responsibility to developers, the better. Everyone hates change, especially developers, so shift responsibility early so that fewer folks need to change in the future.

In addition, get buy in from engineering. Until you get buy in from the CTO the battle has just begun, sometimes even if the mandate comes from the CEO. In reality, putting in place these minimal technologies and process will help speed up development with less vulnerabilities to fix later in the SDLC where it is more expensive and time consuming. If developers won’t take responsibility for the security of their code, it shows a lack of ownership — you can expect non-security bugs and production code to be more like R&D code.

To learn more about application security and secure coding training please visit our blog at https://blog.hackedu.io.

Image for post
Image for post

Co-founder and CEO of HackEDU. Previously a CISO. 15 years in cybersecurity.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store