AWS in 30 recap

Last month, Lead Partner Solutions Architect, David Schott, presented a demo on how Snyk works alongside Amazon Web Services (AWS) to identify vulnerabilities at every level of development and infrastructure.  

David covered why agile development in the cloud requires a different security approach than simply using the IT security methods of the past. Then, he showed a real-time example of how Snyk’s AWS cloud security tools can find and mitigate common vulnerabilities. Let’s dive right into his presentation and its biggest takeaways.

The modern application: A new risk profile

It’s clear that today’s cloud landscape brings countless benefits and opportunities to businesses. Thanks to the adaptable nature of cloud operations and infrastructure as code (IaC), development is more agile than ever. But along with these new advancements in cloud services comes a new risk landscape. 

IT into app services

Before cloud development practices came onto the scene, developers worked according to waterfall methodology. It was all about “throwing your code over the wall,” then letting security professionals handle most of the risks that appeared later down the line. While developers would take responsibility for their own app code and open source libraries, a much bigger portion of security was owned by the IT security team. They focused on mitigating risk within resources such as IT apps, servers, VMs, networks, vSphere, and hardware.

Nowadays, developers are taking much more ownership over the cloud services that house and run their code. Think containers, IaC, and orchestration tools such as Kubernetes. This shift in ownership means that IT security can no longer take sole responsibility for securing cloud infrastructure. Instead, a developer-centric application security approach is required.

“Nowadays, developers are using cloud, containers, and Kubernetes. This means they're moving faster than they ever have before. They also have an increased responsibility for these different areas. And developers aren't experts at everything, so security vulnerabilities definitely creep in.”

Modern apps are icebergs

Take a closer look at any modern application hosted within a cloud service (e.g. AWS) and you’ll find that it’s layered like an iceberg. A single line of code can represent an entire ecosystem of open source libraries, containers, and infrastructure as code. And any of those components can go even further down, because their dependencies often have dependencies! The interconnected nature of today’s applications makes it tough to keep up with cloud security.

How DevSecOps fits into the conversation

The best approach for finding and mitigating risk within this “iceberg” of dependencies is by integrating security measures into every stage of development (a DevSecOps approach). It’s all about placing the right tools into your processes at the right times. For instance, a development team needs to know about static code vulnerabilities as soon as possible so they can mitigate these code issues soon after they’re written. Runtime security controls related to orchestration engines like Kubernetes, on the other hand, can’t enter the picture until much later in the process. So, it’s not enough to just plug a security tool into the process at one stage. Development teams need security coverage at every stage and in every layer of their applications. 

How Snyk works alongside AWS at every stage

As we’ve seen, there is a lot going on behind the scenes of most modern applications. So it’s essential for developers to know how to find and mitigate vulnerabilities in every area of their application — not just within the app code, but in the open source libraries, containers, and cloud infrastructure supporting that code as well. 

Snyk has created tooling for every piece of this puzzle, specifically working alongside cloud services. In his demo, David covered how Snyk provides AWS cloud security tools for each “piece of the iceberg.”

AWS CodePipeline (IDE)

Snyk enables developers to implement security checks into their AWS CodePipeline. Our solution serves as a "security gate" in the pipeline, preventing vulnerable code from moving to the next stage of the development lifecycle. In addition, we give developers and security teams a "live" view of third-party, open source vulnerabilities in real time. With this live feedback, developers no longer have to waste time waiting on periodic rescans.

Snyk's "monitor" functionality also sends scan results to the Snyk UI, for further analysis, continuous monitoring, and rescans. This enables teams to see new vulnerabilities in the Snyk UI, without needing to rebuild the software in CI/CD.

The Snyk-CodePipeline integration is simple to set up as well. Within minutes, Snyk integrates with CodePipeline, either by authenticating with an existing Snyk account or giving users the option to start a new one. Once integrated, users can create a new pipeline with Snyk, or add our security features as a stage within an existing pipeline.

Amazon ECR (container registry) 

The Snyk platform can also integrate with Amazon ECR. In fact, the Snyk vulnerability database is already built into Amazon Inspector as part of our partnership with AWS. Snyk’s functionality enables their tool to scan container images, Amazon EC2 instances, and AMIs for application vulnerabilities. 

Although we’re already built into Amazon Inspector, Snyk Security can add additional insights into your container registry vulnerabilities. Snyk’s platform actively scans your Amazon ECR instance for vulnerabilities within your container images and their base images. We help developers mitigate these risks with recommendations to switch out vulnerable base images for less risky options, and we can open a pull request to make the change in the source code. 

Amazon EKS (Kubernetes environment)

Snyk also has the capability to work alongside runtime environments. Our AWS cloud security tools work alongside Amazon EKS to identify security issues that show up in your containers when they’re in a running state. Similar to the ECR integration, we provide base image upgrade recommendations, as well as additional details on how securely the container is running in Kubernetes. 

AWS CloudTrail Lake

At one point in his demo, David demonstrated how a developer or security expert might ignore a security vulnerability (CVE). User actions like ignores, role or membership changes, settings changes, and so on are all captured as Snyk Audit Logs. Snyk provides an API for customers to access their audit logs, but it has limitations. For example, audit logs are preserved for 90 days, then deleted after that. To remedy this, Snyk integrates with AWS CloudTrail Lake, allowing customers to quickly and easily push their audit logs from the Snyk platform to their AWS environment. AWS CloudTrail Lake offers the ability to query audit logs using SQL, and retain these logs for a configurable period up to 7 years. 

AWS Well-Architected

Snyk reporting capabilities allow customers to “slice and dice” their data in various ways. For example, one can filter security issues to only those that are automatically fixable, with a severity of critical or high, resulting in a smaller, more actionable list of issues to remediate. The Issues Summary page displays trends like new issues vs. remediated issues, and mean time to resolve (MTTR) - and these trends can be further broken down to individual projects or teams. In the context of Snyk Cloud, he showed how cloud misconfigurations are mapped to compliance standards such as HIPAA, SOC2, PCI-DSS, and others. Snyk also supports the AWS Well-Architected Framework, which is focused on 6 pillars such as security, reliability, and others. In a matter of minutes, Snyk customers can scan their AWS environment to identify where they’re falling short of these best practices, then take action to remediate issues and improve their AWS architecture.

AWS security with Snyk

If you want to see our AWS cloud security tools in action, be sure to check out David Schott’s full AWS in 30 Recap presentation. In addition, learn which common AWS misconfigurations might be lurking above the surface of your applications.