DevSecOps is a hot topic at the moment, and particularly relevant when dealing with API development.
APIs are growing at an exponential rate: not onlyĀ are they the backbone of any application, but microservices architecture imply exposing internal APIs for every microservice or group of microservices. The average number of APIs to protect within an enterprise is nearing 500.
In that context, how do we :
- Ensure consistency across all security policies: many prospects we are talking to use multiple API management solutions, deploy applications on various clouds, using different programming frameworks and languages such as Ruby, Node.js or Go.
- Deliver security at speed: 10 or more deployments per week is now the norm.
- Deliver security at scale: hundreds of APIs to deploy, several times per week.
- Catch vulnerabilities early: fixing issues late in the API lifecycle can cost up to 30 times more than at development time.
Meet DevSecOps.
What is DevSecOps ?
āDevSecOps isĀ the philosophy of integrating security practices within the DevOps process.Ā
DevSecOps involves creating a ‘Security as Code‘ culture with ongoing, flexible collaboration between release engineers and security teams.ā
Adopting DevSecOps requires three key elements:
- A change in culture: enterprises need to approach API development differently, breaking silos across Dev, Sec and Ops teams. Many start adopting DevSecOps by building a small team mixing all those roles, who will eventually become the champions for the cultural change from inside.
- A change of tools: when we are adopting DevSecOps for APIs, we are pushing security left, that means in the hands of the developers. Using the tools that security teams use today and putting them in the developers hand will likely not work though. This is what we tagged as “Sh*tting left” at API World! A terminology we borrowed from Jeff Williams. Instead, we want to put in place tools that fit in the developer’s flow as much as possible, so that they can effectively consume and address security issues.
- A change of processes: scale and speed require automation, and enterprise have to change the way they work in order to detect errors (at any stage), automatically inject events into a feedback loop that each API security player can act upon.
Addressing DevSecOps for APIs with 42Crunch
The 42Crunch platform has been built with DevSecOps at its core.
- We empower developers to discover and address issues: using our Audit service, developers can detect vulnerabilities as early as design time by analyzing their OpenAPI files (a.k.a Swagger files). Our online encyclopedia is meant to educate and bring attention to common issues which are at the root of the OWASP Top 10 API risk list. Developers iteratively become better at API security, as they learn from the previous reports and fixes they applied. Security becomes a habit, as opposed to a burden.
- The Scan service help developers pinpoint potential vulnerabilities in the APIs, as we use the OAS-based API contract to test whether the API implementation actually honors the contract. Typically issues detected would be additional supported verbs, data leakage, exception leakage, poor control of Content-Type value, or input validation errors. It helps also detect whether the contract should actually be amended to match the implementation.
- Finally the Protection service can be automatically deployed in front of existing APIs, automatically performs payload inspection based on the OAS contract and block any request/response that does not conform to it.
All 42Crunch services can be piloted via a REST API and deeply integrate into your CI/CD pipelines:
- The Audit service can be added to the CI pipeline, to report on issues and eventually block the deployment of APIs if the audit score is below a defined threshold.
- The Scan service can be added to the CD pipeline, in order to detect issues and report on them, pushing those issues into your favorite issues management, such as GitHub or JIRA.
- The protection can be deployed automatically via the CD pipeline, from Dev through Production and always kept in sync with the latest OAS definition.
Combining those three services, you can detect issues early and deploy protection automatically. The services are meant to be used by developers, so that they can deal with security themselves, but always under the control of the security teams who define how and when the services are injected in the build pipelines.
Security as code
In order for DevSecOps to work well, all security must be described as code. Much like we have tools like Ansible or Chef, or Kubernetes deployment files which describe how the infrastructure is built, we need to have files that describe how security is applied.
At 42Crunch, the OpenAPI file is at the core of this approach: we allow developers to describe the APIs contract, the security (APIKey, OAuth)Ā but also enrich the API with annotations that drive the execution of security policies. This file can be pushed into a code repository, versioned, and tracked together with the APIs implementation and deployment code. It becomes the single source of truth to understand what the API does and how it is secured.
To learn more about the 42Crunch platform, download ourĀ datasheet.
