Businesses continually adopt new technologies to become more efficient and effective. This move toward efficiency in IT has brought a “shift left” to application security testing. Methodologies like DevOps and Agile work with iterative and MVP states, meaning that apps are constantly updating and constantly need testing and retesting – sometimes daily or multiple times per day.
Serverless, cloud native, containers, and Kubernetes are changing how apps are deployed and managed. This has expanded the attack surface in the form of new layers of complexity and more settings and updates to manage, which also means more room for manual error. In a container, this includes the image, registry, and east-west traffic, while in Kubernetes, this includes access and authentication, runtime resources, and network policies. Traffic between apps in a container does not cross perimeter network security, but should still be monitored for malicious traffic between apps and the resources they use.
Your cloud-based ecosystem doesn’t provide comprehensive security
Cloud providers, orchestrators, and other partners don’t provide a full spectrum of security capabilities out of the box – even with their help, your team must create and maintain their own security policies and continuously monitor your ecosystem for any unusual or malicious activity. While network segmentation and perimeter security for your guest VMs or containers might be available, your engineer will typically need to configure that.
The figure below outlines the responsibilities of cloud providers, security vendors, and end-users, across apps, hosts, networks, and foundation services. The responsibilities in purple and orange are primarily the responsibility of the cloud provider and security vendors, but our engineers tell us that they are involved in every cell of this chart in some way.
Treat security as a critical outcome, not a department
Security should be top of mind for everyone in the business, not just your security team. While the complexity of your infrastructure builds, new tools and capabilities give opportunity for everyone to contribute to the security effort. Here are a few areas of change that will help you rally the masses in defense of your business:
- Cloud providers are beginning to offer more security capabilities.
- System updates – and staying current with your patches – could very much save the day.
- Automating your processes could make or break the business. While guidelines for humans are necessary, you need automation to abstract the complexity of your infrastructure. Soon, automated capabilities to translate plain-language policies into the growing multitude of settings will make their way into the market.
Take a Zero Trust approach to your applications
The foundational idea of Zero Trust is simple: Trust nothing and always assume the bad guys are trying to get in. It’s time to take your security beyond the traditional network-perimeter approach and extend Zero Trust from data, network, and endpoints to your application infrastructure. It also wouldn’t hurt to protect the software development lifecycle (SDLC) to ensure the integrity of your software is not compromised, given all of the automation in a typical DevOps toolchain.
Three key principles to secure next-generation IT
1. Enhance your security practices with DevSecOps
As you iterate on software, dovetail security into each iteration through DevSecOps – not simply to test security for the entire history of the app, but to test the impact of each change made in every update. Retrofitting your apps and software for secure functionality will slow down your release cycle. Marrying the two will save both time in the present, and heartache in the future when your software is inevitably attacked. Unfortunately, traditional methods don’t fit the bill when it comes to DevOps; it’s too expensive and too robust to scan every piece of code manually. With a shift left strategy, security scans can be automated into every code commit – meaning you no longer need to choose between risk, cost, and agility.
Arm your developers to resolve vulnerabilities early in the SDLC, leaving your security team free to focus on exceptions. With GitLab, a review app is spun up at code commit – before the individual developer’s code is merged to the master. The developer can see and test the working application, with test results highlighting the impact of the code change. Dynamic application security testing (DAST) can then scan the review app, and the developer can quickly iterate to resolve vulnerabilities reported in their pipeline report.
Learn more about DAST in GitLab's product documentation.
2. Secure horizontally before digging deeper
We often fall into the trap of going deep on a single aspect of security – leaving other obvious aspects completely exposed. For instance, you may use a powerful scanner for your mission-critical apps but neglect to scan others; or, you may choose to save resources by not scanning your third-party code, with the assumption that its widespread use means it’s checked out.
Avoid focusing so much on application security that you forget about container scanning, orchestrators, and access management.
3. Simplicity and integration wins
The key is to bring security scanning to the development process by having a tool like GitLab that allows developers to stay within the same platform or interface to both code and scan. Making the process easier increases the likelihood that it’ll get done – and making the process automatic within the tool ensures that it will happen every time there is a code update.
Ready to deliver secure apps with every update? Just commit.
Cover image by Frank McKenna on Unsplash
