Snyk recently launched a multi-day live hack series with AWS, where experts demonstrated exploits in real-time and explained how to defend against those vulnerabilities. This series helped viewers discover new ways to improve security across the application stack for AWS workloads. As part of the series, Micah Silverman (Director of Developer Relations, Snyk) and Chris Walz (Senior Security Engineer, Atlassian) discussed Log4Shell.
Kubernetes uses secret objects, called Secrets, to store OAuth tokens, secure shell (SSH) keys, passwords, and other secret data. Kubernetes Secrets allow us to keep confidential data separate from our application code by creating it separately from pods. This segregation, along with well-formed role-based access control (RBAC) configuration, reduces the chances of the Secret being exposed — and potentially exploited — when interacting with pods, thereby increasing security.
Similarly to our previous research on “Secrets Detection,” during the development and testing of JFrog Xray’s new “Contextual Analysis” feature, we wanted to test our detection in a large-scale real-world use case, both for eliminating bugs and testing the real-world viability of our current solution.
Recently, I met with Or Weis — a Snyk Ambassador — to discuss access control in the cloud. Or is an entrepreneur, based in Tel Aviv, where he founded Permit.io, a solution that empowers developers to bake in permissions and access control into any product in minutes and takes away the pain of constantly rebuilding them.
You didn’t change anything in your code, yet the scan is different this time. Here’s advice from an Application Security Consultant on why that may be. Have you ever wondered why you scan code one day and get one result, and then scan the same code a month later and get different results – even though you never changed anything?
Fortinet’s newest vulnerability, CVE-2022-40684, allowing for authentication bypass to manipulate admin SSH keys, unauthorized downloading of configuration files, and creating of super admin accounts, has put a big target on the backs of unpatched and exposed Fortinet devices.
Many security engineers have woken up to dozens of Slack messages and emails telling them the day they dreaded is here: a vulnerability has been deployed, and now it must be fixed. Meetings and plans are abandoned while security engineers rush to fix the problem. It’s often a process failure that has led to the now-urgent issue. And these emergency issues can appear across a spectrum that includes all types of remediation efforts.
