{"id":11189,"date":"2022-02-15T17:01:09","date_gmt":"2022-02-15T17:01:09","guid":{"rendered":"https:\/\/staging-site.42crunch.com\/?p=11189"},"modified":"2022-11-28T15:26:32","modified_gmt":"2022-11-28T15:26:32","slug":"how-developers-can-become-api-security-champions","status":"publish","type":"post","link":"https:\/\/staging2022.42crunch.com\/how-developers-can-become-api-security-champions\/","title":{"rendered":"How Developers Can Become API Security Champions"},"content":{"rendered":"
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 \u2014 thankfully most developers are at least now aware of what an SQL injection attack is.\u00a0 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.\u00a0\u00a0<\/span><\/p>\n 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.<\/span><\/p>\n What can an individual developer do?<\/strong><\/p>\n 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.\u00a0<\/span><\/p>\n What can companies do?<\/strong><\/p>\n 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.<\/span><\/p>\n Companies should afford developers the following:<\/span><\/p>\n 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.<\/span><\/p>\n What can security teams do?<\/strong><\/p>\n The third element to consider is the role played by the security team in improving API security.\u00a0<\/span><\/p>\n 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.\u00a0<\/span><\/p>\n 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.\u00a0\u00a0<\/span><\/p>\n 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 \u201cbuild paved roads\u201d so security teams should not get in the way of developers rather, \u201chitch the security wagon to developer productivity\u201d.<\/span><\/p>\n Netflix Case study<\/strong><\/p>\n Philippe shared the following Netflix case study as an exemplary security journey.\u00a0<\/a><\/strong><\/p>\n In 2017 Netflix were faced with a challenge of how to scale their security function \u2014 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.<\/span><\/p>\n 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 \u201cPaved Road\u201d 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 \u2014 the example provided is that of the \u201cWall-E\u201d Cloud gateway product which provided standard implementations of common authentication patterns.\u00a0<\/span><\/p>\n The security team then sought out early adopters to embrace \u2018Wall-E\u201d as part of their product, and then reworked their checklists to drive developers toward \u201cWall-E\u201d as a pre-approved out-of-the-box solution. Only when a team had a peculiar requirement that precluded the use of \u201cWall-E\u201d would they use a custom solution which would then require the full checklist. When these exceptions were encountered the security team would enhance the \u201cWall-E\u201d product to include the required custom features. As such the \u201cWall-E\u201d 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 \u201cPaved Road\u201d products.<\/span><\/p>\n Their key takeaways are:<\/strong><\/p>\n Who has primary responsibility for implementing API Security?<\/strong><\/p>\n Finally <\/span>during a recent 42Crunch webinar <\/span>\u201cAutomate API Security with Security as Code\u201d<\/span><\/a> 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.<\/span><\/p>\n <\/p>\n <\/p>\n Learn how the<\/strong> 42crunch platform builds security into the development process<\/a><\/span><\/p>\nQuestion: How do we get developers engaged in API Security?<\/strong><\/h4>\n
\n
\n