Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

In a previous blog post, we showed how type manipulation (or type confusion) can be used to escape template sandboxes, leading to cross-site scripting (XSS) or code injection vulnerabilities. One of the main goals for this research was to explore (in the JavaScript ecosystem) how and if it is possible to bypass some security fixes or input validations with a type confusion attack (i.e by providing an unexpected input type).

Most container images are built using Dockerfiles which contain combinations of instructions like FROM, RUN, COPY, ENTRYPOINT, etc. to build the layers of an OCI-compliant image. One instruction that is used surprisingly rarely, though, is LABEL. In this post, we’ll dig into labels (“annotations” in the OCI Image Specification) what they are, some standardized uses as well as some practices you can use to enhance your container security posture.

We are thrilled to welcome the team at CloudSkiff to Snyk! Many of you may be more familiar with driftctl, the open source project started by the CloudSkiff team. I wanted to share with you why we’re excited about the addition of this fantastic group of people to Snyk, and our plans for the future of Snyk Infrastructure as Code (Snyk IaC), as well as our commitment to keeping driftctl open source.

Risk management of code is an important and often overlooked development function that you need to pay attention to. You may think that this is not a developer’s problem, however developers should not write code that unduly adds to technical debt, hence the need to manage risk. The primary motivation for risk management is to prevent error or failure. Do not seek to eliminate failure, seek to minimise it, to manage the risk of failure.