Skip to main content

How automation is key to cloud-native application security

(Image credit: Image Credit: MNBB Studio / Shutterstock)

Implementing automated security procedures has very quickly become a necessity at companies deploying software at scale to the cloud. Understanding the why, what and how of this might allow organizations to make better decisions on cloud security - and facilitate better, secure applications.

Modern, cloud-first organizations move at a breathtakingly fast pace. Larger organizations might make deployments several thousand times a day, while the number of code changes might come to the hundreds of thousands over the same period. 

Adding to this, technology-centric companies might employ hundreds of developers: it becomes extremely difficult in these circumstances to track and understand every project, or follow exactly what they’re doing. This speed and volume of operations has meant that security procedures devised for earlier times, when the security team would inspect and test code prior to deployment, are no longer functional or practical. 

Following the successful adoption of DevOps, we have now entered the era of DevSecOps, in which security teams shift focus to empowering developers to build more securely, and where developers assume responsibility for secure code, built on secure foundations, in securely configured cloud environments. 

If this sounds like a whole lot of extra work, it is compounded by the fact that only around 20 percent of the code in a typical cloud application is unique to that application, the rest comprising Linux operating system files, open source libraries, their dependencies and other inherited elements. Developers need more help to identify any potential vulnerabilities in applications, their broader codebase and their configurations. A highly sophisticated security toolset needs to be assisted through automation.

Security automation at work 

This automation can take a number of forms, and the first steps into this arena will depend upon what is practical for an organization, and its key pain points. Probably the first step is to ensure the application and its components are scanned for vulnerabilities automatically at set intervals. As a Senior Security Engineer at an American cloud communications platform-as-a-service company says: “Automation is the key to building security at scale, because it eliminates human error. When we automate, we catch more vulnerabilities.” Humans need to remember to scan under normal circumstances, and for even the most disciplined teams, that creates a potential point of weakness, plus it is an extra job that doesn’t need to exist if automation is already in place.

The team at the aforementioned cloud communications company has taken this species of automation a step further. They have created a GitHub app which leverages the tool’s API to monitor the main branch of the company’s application for changes and pull requests. When a pull request is merged to main, it automatically imports the project for scanning. It also reacts when projects are created, deleted or renamed, triggering the appropriate security actions. It is great that the company has now open-sourced the tool, allowing others to benefit from its innovation.

At a major online travel agency, visibility into the existence of unmitigated vulnerabilities was a particular concern. The organization was experiencing the symptoms of rapid development at scale noted earlier, and needed to create automated assistance. One of its leading software engineers noted: “Manually reviewing [code and configurations] would just be a nightmare at the scale we’re operating at.” The company decided to build its own dashboard application to provide developers and managers the visibility they needed into security across projects using API calls to gather information from its security tools.

The need for assistance with pipeline flow was what led an American media company to create its own internal application, which detects new container images via Cloudtrail, scans them for vulnerabilities and uses its security tool’s API to get the results and processes that information to create Jira tickets for the relevant teams and developers. The company’s director of platform engineering says the business works with thousands of container images, and up to 7000 code repositories. Only through automating as much of the workflow as possible could it feel confident that risks were being consistently spotted and mitigated.

Automation without tears 

As organizations continue to automate, several considerations must be applied in order to achieve the very best results. The first of these might well affect the overall choice of security tools and is the adaptability of the tools you wish to automate. The availability of a powerful and well-documented API might not always seem like a priority when decisions are being made, but will empower the creation of security automation tools which work exactly as the organization needs. For other organizations, typically those with smaller teams, the availability of an SDK native to their programming language of choice will be an absolute necessity.

A second key point, highlighted by the director of platform engineering at the media company, when the company developed its own internal application, is to carefully consider the results of automation. If a scan might conceivably detect thousands of vulnerabilities, then simply creating tickets for all of them could quickly create a log jam of low level jobs and a very frustrated development team. Instead, the system filters out vulnerabilities which are unfixable or which cannot be exploited, and prioritizes tasks according to how much impact they will make on the security of the application. The system also makes it far easier for developers to work through tickets, offering advice on the availability of patches as well as links to documentation describing the nature of the vulnerability.

A last point about automation projects is to be sure to always remember the goal is to make life as easy as possible. Creating new processes, new tools to work with or hoops to jump through may be a retrograde step. Wherever possible, aim to use the tools your developers already work with on a daily basis, whether that’s through their IDE, repositories or ticketing systems. When automation enables security without increasing friction, then that’s the ideal combination organizations should work towards.

Daniel Berman, Product Marketing Director, Snyk

Daniel Berman is Product Marketing Director at Snyk, the leader in cloud-native application security.