How Developers Can Become API Security Champions

Question: Everyone is talking about DevSecOps, why are we not able to fix the security issues?

Despite the obvious challenges, Colin believes that the industry has made progress as compared to ten years ago when very insecure code was prevalent. Today’s code is definitely more secure and security is improving — thankfully most developers are at least now aware of what an SQL injection attack is.  Philippe also thinks things are improving, however, he sounds a note of caution, mindful of the ever increasing volume of APIs and related attacks he fears it is not obvious that the industry is keeping pace with these new targeted threats. The landscape has definitely become more complicated and things are moving fast. He notes that it is a challenge for developers to keep up with the security guidelines and ever changing threats.  

Question: How do we get developers engaged in API Security?

Although developers can do a lot to educate themselves about API security, companies and security teams also need to make positive changes to their approach to get the best results and prevent security blockages, security issues and development delays. So Philippe answers this question by looking at each entity individually.

What can an individual developer do?

Developers need to have a solid security awareness just like they know how to write code that performs well. They should push for security training to ensure they have the basic awareness of what it means to build secure software. While every developer does not need to be a security expert, they should realize that their actions may have security consequences and consequently need to know who to ask on the security team or who is the security champion on their team. 

What can companies do?

Philippe advocates that companies must provide their developers with the resources to implement security. Sometimes companies are reluctant to invest enough as security is often perceived as an additional overhead, but the benefit of providing development teams with the correct tools, far outweighs the downside, and will save the company money and protect their reputation, and reduce the costs of breaches or expensive security updates.

Companies should afford developers the following:

• Time to learn about security because if they never have time to learn about it they will not be able to improve. 
• Time to build out features securely. 
• Provide a developer with reference components or patterns that are vetted and validated to be secure.

Philippe is observing an increasing trend amongst early-stage and start-up companies that are adopting a developer-first approach to attempt to get security right from the start, and believes this is already having a tangible impact.

What can security teams do?

The third element to consider is the role played by the security team in improving API security. 

Typically the security team brings a long checklist or guidelines and expects the development team to implement all of these checks. They find it difficult to get developers to actually implement the security guidance due to time constraints. 

Philippe has come to the realization that this list-based approach is never going to work as you can never expect every developer to know everything on the list and never make a mistake. Instead of having a long list of guidelines, recommendations, and checklists for reaction-based security, he advocates that security teams adopt a collaborative approach that empowers the developer to code in security as part of the design and development process.  

In other words, avoid making security an add-on that needs to be done, make sure it is part of the process from the beginning. For Colin, the one thing that has really struck home for him was the term “build paved roads” so security teams should not get in the way of developers rather, “hitch the security wagon to developer productivity”.

Netflix Case study

Philippe shared the following Netflix case study as an exemplary security journey. 

In 2017 Netflix were faced with a challenge of how to scale their security function — on the one hand they were facing business challenges to build new functionality faster than competitors, yet were being pressed to raise the bar of security for internet-facing assets.

The key observation the security team made was that developers were faced with too many checklists which caused frustration, and slowed development without any significant security benefit. Certainly this approach was not scalable. The security team pioneered the concept of a “Paved Road” which is essentially a set of standard security features and functions available to development teams for adoption in their products. The security teams would provide an approved, validated security solution as a product — the example provided is that of the “Wall-E” Cloud gateway product which provided standard implementations of common authentication patterns. 

The security team then sought out early adopters to embrace ‘Wall-E” as part of their product, and then reworked their checklists to drive developers toward “Wall-E” as a pre-approved out-of-the-box solution. Only when a team had a peculiar requirement that precluded the use of “Wall-E” would they use a custom solution which would then require the full checklist. When these exceptions were encountered the security team would enhance the “Wall-E” product to include the required custom features. As such the “Wall-E” product became all encompassing, and adoption grew within Netflix. Also by understanding the developer intent (what problem were they solving) the security team could further evolve their standard “Paved Road” products.

Their key takeaways are:

• Build a bulletproof authentication mechanism and make this a part of the standard architecture.
• “Productize” capabilities to drive adoption and standardization.
• Hitch the security wagon to developer productivity.
• Understand the intent, and provide value around this.

Who has primary responsibility for implementing API Security?

Finally during a recent 42Crunch webinar “Automate API Security with Security as Code” we conducted a poll asking enterprises who was the primary responsible for implementing API security. The results are encouraging and indicate that companies are increasingly moving to adopt a developer-first approach to implementing security.

Learn how the 42crunch platform builds security into the development process

Learn more on the webinar series: API Security Landscape Today and the OWASP API Security Top 10 Challenges

Speakers: