Within the emerging practice of DevSecOps there is no term more ambiguous than ‘shift left,’ a term likely to mean something subtly different depending on whom you ask. A commonly accepted view is that ‘shift left’ for security fosters the adoption of security practices as early as possible in the development lifecycle. This includes activities such as threat modeling, capturing security requirements, architecture review, and most vitally the integration of security testing tooling within developers’ native environments. For developers, this requires developer-friendly security tooling, typically operating with low latency, low in false positives, and adding value to the developer workflow. For security teams, this ‘shift left’ approach has meant developing a new set of skills, namely becoming familiar with development tools (think Git, CI/CD pipelines, containers, etc.) and delegating the operation of the tools to developers. Ideally, the ‘shift left’ approach allows security teams to focus more on policy, compliance, risk reviews, and mitigations — where security sets the ‘guardrails’ for developers who then operate their process within these rails.
How does this impact API security?
Recently there has been an increased focus on API security within organizations driven by the increased adoption of APIs and the attendant high-profile breaches affecting APIs. Unfortunately, much of the existing security tooling (such as SAST and DAST) is not effective at discovering vulnerabilities within API implementations which requires a rethink in the approaches toward API security. Fortunately, through the wide-scale adoption of the OpenAPI Specification (OAS) as the single ‘source of truth’ within an organization, forward-thinking security teams can drive API security to the ‘far left’. Using an OAS contract it is possible to encapsulate both the data domain (via the endpoints and the data requests and responses) and the security domain (the authentication and authorization requirements and additional factors such as rate-limiting, token validation).
What does this mean for developers?
From a developer perspective, this ‘contract first’ approach requires a shift in thinking away from coding first towards an upfront design. The benefits are numerous — a well-designed contract can allow for the automatic generation of backend coding stubs (via tools like Swagger Codegen) and the generation of automated tests (via tools like Newman), as well as the automatic generation of UI frontends for the API (such as Swagger UI), and automated documentation.
The most important benefit of this ‘contract first’ approach for developers is to allow them to gain visibility into the security of their API code as they are developing it. Firstly various plugins can be used to perform active validation of the API contract as it is developed (for example detecting where no security constraints are specified on endpoints). Secondly, developers can test the implementation of their API backends using scanning tools to verify that their implementation matches the specified contract. This validation and verification can be done in the immediacy of the developer IDEs minimizing friction in adopting proactive security methods.
Security becomes everyone’s responsibility
Another core practice of a ‘shift left’ based development process is continuous integration and continuous delivery (CI/CD). Using an API contract it is possible to add gating controls to the pull-request (PR) process to ensure that proposed code changes adhere to the contract. Security teams can also implement gating controls in the delivery process to ensure that the deployable artifacts have the appropriate security controls. This is analogous to the approach used in Infrastructure-as-Code where Terraform deployments are validated before deployment to ensure that — for example — relevant network controls are implemented.
As an extension of this approach, the security team can inject API security controls into an API backend as part of the deployment process. This ‘security as code’ approach allows segregation of duties between the development team and the security team — the security team can enforce perimeter controls (such as rate limiting and token validation) and free up the developers to focus on the data contract and input and output validation. Using an automated approach within the CI/CD process guarantees the controls are in place and removes the likelihood of human error, typically a developer racing to a deadline forgetting a vital control.
Conclusion
This developer-first approach to security is undoubtedly gaining momentum as it accelerates the overall delivery time for new APIs and applications and reduces cost overruns. By directly addressing the security bottlenecks that have evolved due to traditional negative security models, a positive security model that embraces shift-left combined and shield-right methodologies is the way forward for modern enterprises.
By taking this approach security teams need not feel that they are abdicating control to the dev teams. On the contrary, enabling “security-as-code” practices will free up the security team to focus on ensuring policies are being complied with and ensure the overall governance and risk management framework of the enterprise is optimized.
This approach addresses the gap between your security and development teams and is the panacea of security being everyone’s responsibility — meaning the right security controls are included by the right team at the right time and all facilitated by the power of the OpenAPI Specification.
