In the first part of this blog series, we looked at security best practices for the base images which you might be using. But what happens to container image security when we add other things to it? Perhaps we’re installing additional software from upstream, and we’ve got custom applications of our own which might have their own dependencies also being installed.
If you’re doing open source development today, chances are high that you’re active within the GitHub community — participating in open source projects and their repositories. A recent addition to the GitHub ecosystem is GitHub Packages, which was announced back in 2019 and is now receiving even more updates with the general availability of the GitHub Packages container registry.
Misconfigurations in infrastructure as code (IaC) can be just as dangerous as vulnerabilities in code. Small mistakes in configuration can lead to the sensitive data being readable on the internet, or private endpoints and dashboard accessible to the anonymous users and abused as the initial point of compromise. Recent security research findings indicate the rise in malware targeting the Kubernetes platform which showcases the need for secure configuration.
When you start scanning your container images, it can be disconcerting to discover that you have large numbers of vulnerabilities. Below is a scan I did last week on a vulnerable node image that I built. While a fairly extreme example, you can see that this image out of the box is showing as having over 800 vulnerabilities in it.
I recently caught up with Phil Guimond, Principal Cloud Security Architect at ViacomCBS. He describes his role as a fancy way of saying he likes to be involved in All The Things™. This includes cloud security and architecture, application security, penetration testing, and digital forensics and incident response, and even vendor reviews and risk management from time to time. He works in a very cross-functional team. We had a great discussion, and I wanted to share it with all of you.
Machine learning is a loaded term. While machine learning offers amazing potential for advancing technologies, it often gets used as a marketing buzzword describing glorified pattern recognition. So it becomes increasingly difficult to know if the application of machine learning to existing technology is going to break new ground or sell more licenses. That’s the problem that Frank Fischer, Product Marketing for Snyk Code, explores in his RSAC 2021 talk ML in SAST: Disruption or Distraction.
Following on from my previous post on testing for PHP Composer security vulnerabilities, I thought this post might be useful in helping create more secure applications that prevent PHP code injection. As developers, we build apps to help make end users’ lives easier. Be it entertainment, workplace or social network application, the end goal is to protect the users we build for by ensuring we build security into the code.
If you’re a Java developer that wants to develop your applications more securely, you’ve come to the right place. Snyk can help you with that mission. This article will explain how to begin with Snyk for secure Java development so you can be more secure from the get-go. If you’re new to Snyk, it’s important to know that we offer a variety of developer-focused products and tools. Some of these tools, like our CLI and some IDE integration, support multiple products.
Snyk is excited to announce the general availability of Snyk Container as an officially supported and published extension in the AWS CloudFormation Registry! The CloudFormation Registry lets you manage the extensions that are available for use in your CloudFormation account. Public third-party extensions, like Snyk Container, are made available in the registry for use by all CloudFormation users alongside those published by Amazon and must be activated before use on your account.
