Industry Insights

The Shift Left Approach and Cloud App Development Security

January 17, 2022

by

Tal Katz

Cloud & IT Security Director

The Shift Left Approach and Cloud App Development Security

shift left approach, cloud app development, cloud application development, cybrella cybersecurity experts

Our previous blog discussed how cloud applications create a faster and more efficient process than traditional applications. Application development works similar to a factory pipeline: code goes in on one end, then the product comes out the other. Everything is done automatically, which increases speed and efficiency.

However, this can make security a challenge compared with slower application development methods. How can cybersecurity experts ensure that their data remains secure when creating apps?

Ensuring secure app development is a problem for many companies: 79% of organizations push vulnerable code to production occasionally or regularly. What’s worse is that many of these companies don’t even realize that they are doing so. In the same survey, these organizations rated their application security as pretty good.

How can organizations maintain their security while embracing the fastest and newest technology? The “shift left” approach is one of the most successful ways organizations can protect themselves most efficiently and cost-effectively.

Here is what you need to know about the shift left approach and the five stages of testing to help improve your application security.

The Shift Left Approach Explained

Shift left is where bugs, vulnerabilities, and defects in the code are caught as soon as possible. That way, it is closer to the developer’s desktop. Application developers need to foster a shift left approach because it costs much less to fix them while they are still near the development stage.

It’s helpful to use the factory analogy again. It can be challenging, costly, and time-consuming to fix when a car is already built. However, it is much easier to make changes in the design phase.

Likewise, in the shift left approach, security testing finds the defects closer to the developer,  making them faster and easier to fix — helping ensure the organization's security is not at risk. The shift left approach requires a series of tests to catch any potential issues before they are off the developer’s desktop.

Test #1: Software Composition Analysis

The shift left approach can be accomplished through a series of "security gates," where potential security lapses can be caught and amended before they become a serious hazard or challenging to fix.

The first test, or security gate, is right on the developer’s desktop. When the developer Is trying to combine external libraries, external components (like open-source libraries), the Software Composition Analysis (SCA) tests all of these components.

The SCA ensures the security of the software that the developer integrates. It answers critical questions about its integrity: Can the organization rely on it? Does it have security vulnerabilities? Is there the right licensing that the organization needs? Does the open-source developer have a reputation for keeping up with code and making changes as necessary?

These are all considerations that the proper testing will be able to answer. It also means that organizations can catch a potential issue before writing code.

Test #2: Static Application Security Testing

Once the components have passed the first security gate, the developer can get to the business of writing the code and completing a function on a specific piece of code. This leads to the next security gate, Static Application Security Testing (SAST).

With SAST, the security program reads the code with white box testing to ensure that the code is secure. The test verifies, for instance, that the developer didn’t neglect any input verification. It also checks that the libraries are up to date.

SAST is not done just once while the developer is writing code. Instead, it is done repeatedly, as the developer completes functions on each piece of code. In the past, this was done manually and took considerable amounts of time and effort.

However, this is now an automatic process that helps maintain the shift left approach. The testing software can pick up on any issues almost immediately so that developers can correct them while still writing the code. It can even be done while the developer is still typing.

Test #3: Infrastructure as a Code Security Inspection

Once everything has passed through the first two security gates, the developer has a version and has already created a feature. Now it is time to deploy this version into the test environment.

This is where the third security gate is critical. It requires testing the environment to ensure that it is not vulnerable to potential security lapses. This test is called Infrastructure As Code (IAC) security inspection. This testing ensures that the configuration is secured without open ports or open buckets, for example. It also ensures that only secure images are used — it is common for developers to download pictures from the internet that could be embedded with a virus.

Test #4: Dynamic Application Security Testing

Once the code runs in the test environment, Dynamic Application Security Testing (or DAST) is the fourth security gate. This testing does not read the code but instead runs it and tries to manipulate it in black box testing.

DAST puts in a large size input, tries different decodings, and utilizes stress loading to try to break the code. In previous times, this was done manually, like SAST. However, now it can be done automatically to speed the process and more accurately catch any potential issues.

Test #5: Embedded Secrets

Once it has passed through the test environment, the last security gate is Embedded Secrets. This test runs the code to ensure there are no application secrets or secret keys within it before it goes to production.

Sometimes, developers will accidentally leave critical authentication keys embedded in the code for convenience. However, the code is not the place to keep security secrets. In fact, eight in 10 incidents in the cloud environment involve these secret keys. Instead, they need to be stored in a safe location where other services and individuals cannot get a hold of them. This last test can ensure that organizations are not putting out sensitive information with the new code.

Automated Security Testing for Secure App Development With Cybrella

With the implementation of a standardized testing process throughout the development of new code, organizations can keep up with technology without jeopardizing their data. Regular security gates throughout the coding process will also ensure that your developers can catch and correct quickly.

Need to create a safety process for your application development? Reach out to one of our Cybrella cybersecurity experts today at cybrella.io to get more information on cybersecurity services. Our cyber solutions can help you make the most of your cloud development without compromising security.

Resources:

Constantin, L. 2020. The state of application security: What the statistics tell us. CSOonline. Retrieved from https://www.csoonline.com/article/3571268/the-state-of-application-security-what-the-statistics-tell-us.html

MORE News

Related Posts