Shift Left, Shift Right, or Other?

Author
Impart Security
Published on
April 16, 2024
Read time
5
Impart Security
April 16, 2024
5
min

The phrase "shift left" is frequently used in software development, referring to the practice of integrating security considerations earlier in the development process. But is shifting left enough to protect our APIs? This post explores the idea that a comprehensive approach to API security—shifting left, right, and otherwise—is required for robust protection.


Understanding the Shift Left Concept

In the realm of API security, the concept of "shift left" implies integrating security measures into the earliest stages of API development. This practice is rooted in the understanding that addressing security issues at the development stage is not only more efficient but also more economical and less risky than addressing them at later stages.

For instance, one aspect of the shift-left approach is the adoption of secure design and coding practices. Here, developers are educated in the nuances of secure coding protocols pertinent to APIs. They are then expected to integrate these principles—such as least privilege, input validation, and secure error handling—right from the inception of the design phase.


The shift-left methodology also incorporates the usage of static application security testing (SAST). In this approach, security is examined at the coding level. SAST is a white-box method of testing used to unearth security vulnerabilities embedded within the application code. Various tools, such as Veracode or SonarQube, automate these checks, providing developers with the ability to catch and rectify issues promptly.

Contrasting SAST, dynamic application security testing (DAST) forms another facet of the shift-left approach. DAST is a black-box testing technique used to inspect running applications for security vulnerabilities. Tools like OWASP ZAP help test APIs, highlighting any potential security loopholes.


Software composition analysis (SCA) is another critical component of shift-left security. It aims to identify open-source components within the software that may have associated vulnerabilities. Tools like WhiteSource or Black Duck facilitate this analysis.

Finally, the integration of security measures into continuous integration/continuous deployment (CI/CD) pipelines underlines the essence of the shift-left approach. With this integration, automated security checks become a part of each code commit. Jenkins, CircleCI, or GitLab CI are some platforms that can automate this process, running tools like SAST, DAST, and SCA.


By incorporating a shift-left approach, API security becomes a shared responsibility throughout the development lifecycle, from the inception to deployment. This comprehensive methodology significantly reduces vulnerabilities and fortifies the API against potential security threats from the get-go.


The Limitations of Shift Left

The "shift-left" approach in API security offers many advantages, including early vulnerability detection, but it's not without its challenges. The approach's strong emphasis on pre-deployment stages can inadvertently overlook runtime and post-deployment security concerns, potentially leaving APIs vulnerable to emerging threats.

Moreover, shift-left relies heavily on developers' expertise in security, which may vary greatly across teams. The assumption that most vulnerabilities can be identified and fixed before deployment also neglects the reality of a dynamic and evolving threat landscape.

Lastly, the shift-left approach predominantly focuses on development and testing stages. This narrow focus can limit the scope of the security strategy, leaving areas of the API lifecycle potentially under-protected. Therefore, while beneficial, shift-left is most effective when combined with other strategies, like shift-right, to ensure a comprehensive and resilient API security framework.


Shift Right - Runtime Security

"Shift right" emphasizes the importance of runtime security controls, a critical consideration ensuring APIs are protected during their operation. While the shift-left approach focuses on the incorporation of security measures during the design and development stages, the shift-right concept recognizes the dynamic nature of APIs and the evolving threat landscape.


A fundamental aspect of shift right is the consistent monitoring of APIs in real-time. It’s about identifying and detecting anomalies and potential breaches promptly. Tools such as Elastic Stack or Splunk are commonly employed for this purpose. By providing real-time insights into API activities, these tools enable immediate detection and remediation of security threats, thereby minimizing potential damage.


The usage of API gateways also plays a significant role in runtime security. API gateways, like the Amazon API Gateway or Kong, act as the robust line of defense between the client and your backend services. They enforce security policies, manage access control, and throttle traffic, which can protect against a range of security issues but require investment to set up and maintain.


Web Application Firewalls (WAFs), such as those provided by AWS WAF, are another essential element of shift-right security. WAFs protect APIs by filtering and monitoring HTTP traffic between a web application and the internet, helping to defend against threats such as cross-site scripting (XSS), SQL injection, and other OWASP API top 10 risks.  The downside to WAFs, however, is that they are also expensive to set up and maintain due to their lack of intelligence and dependence on regex pattern matching.



The Hidden Operational Costs of Shift Left and Shift Right

Although each component discussed so far does have it's own security capabilities, stitching them together into a cohesive, functioning system is extremely complex and difficult.   Let's walk through a simple example:


Imagine an organization attempting to integrate a Static Application Security Testing (SAST) tool like SonarQube, a Dynamic Application Security Testing (DAST) tool such as OWASP ZAP, a Security Information and Event Management (SIEM) system like Splunk, and a Web Application Firewall (WAF) like AWS WAF into a cohesive API security solution.


Firstly, each tool must be individually configured, requiring specialized knowledge about each tool's working and setup. The organization would have to invest significant time and effort into understanding each tool to ensure it's correctly configured and optimized.

Next comes the task of facilitating communication between these tools and existing systems. This often demands the creation of custom scripts or employing middleware to enable smooth data exchange, which can be quite challenging, especially when dealing with tools from different vendors.


Moreover, each tool produces output in its unique format, presenting a challenge when trying to consolidate this information. It might require developing custom parsers or converters to standardize the data for unified analysis. For instance, integrating data from AWS WAF with Splunk for analysis may require creating custom scripts to extract, transform, and load the data into the SIEM.


Scaling also presents a challenge. As the organization's API ecosystem expands, it must ensure these tools can handle the increased load. This necessitates regular monitoring and adjustments to handle growing numbers of APIs, user traffic, and data without impacting performance.


Finally, keeping these tools up-to-date and secure in the face of evolving cyber threats is another significant challenge, requiring continuous maintenance, updates, and patches. It’s a delicate balancing act to ensure all components of the system function harmoniously while providing robust API security.


An Integrated Solution that Spans the Lifecycle is Better for Practitioners

Navigating API security with various separate tools can be complex. However, an integrated solution that includes static analysis, runtime protection, and real-time monitoring offers a more streamlined and efficient approach.


Eliminating the need for bridging different tools, such a solution saves valuable time and resources. It provides a unified view of API security, replacing fragmented insights with a comprehensive understanding, improving decision-making.


Furthermore, an all-in-one solution enhances threat response times. Real-time monitoring coupled with runtime protection can swiftly identify and mitigate threats as they emerge, avoiding delays of shifting between systems.


Lastly, maintenance becomes more straightforward with a single platform. This streamlines the process of keeping the system secure, updated, and optimized. In short, an integrated, holistic solution simplifies API security management, enhancing efficiency, and boosting confidence in handling evolving threats.


Choose Your Path Carefully

In Summary, both shift left and shift right approaches offer their own unique advantages and both strategies should be something that security professionals pursue.  However,

it is crucial not to overlook the hidden operational costs that come with integrating shift left tooling with shift right tooling into a system that can be operated efficiently.  


When charting out a security strategy, security professionals should be mindful of not just feature functionality in their security tools, but also the total cost of ownership including integration and operational costs.


Meet a Co-Founder

Want to learn more about WAF and API security? Speak with an Impart Co-Founder!

See why security teams love us