As applications grow more complex, they incorporate many third-party libraries and open-source components, often making it challenging to fully understand and manage the security risks they introduce. To address these concerns, application security engineers are increasingly turning to tools that provide greater visibility and control over software components.

Okta Bcrypt Authentication Bypass Explained Last week, on October 30th, Okta released an interesting security advisory detailing a vulnerability that could potentially lead to an authentication bypass. According to Okta, the vulnerability was discovered during an internal review and was promptly addressed. Okta was transparent about the issue, sharing the details publicly.

In this two part blog post we will take a deeper look at eBPF and some of its known vulnerabilities. After a quick introduction to eBPF, how it and its ecosystem works, common attacks, we will talk about how automation and fuzzing can help you to harden your eBPF applications.

CVE-2024-45409 is a critical vulnerability in the Ruby-SAML (affecting versions up to 12.2 and from 1.13.0 to 1.16.0) and OmniAuth SAML libraries. It hence effectively poses a security risk for unpatched versions of GitLab (read more on the GitLab blog). This vulnerability arises from improper verification of the SAML Response signature. An attacker with access to any signed SAML document can forge a SAML Response or Assertion with arbitrary contents.

CVE-2023-2163 is a critical vulnerability in the Linux Kernel, specifically affecting kernel versions 5.4 and above (excluding 6.3). This vulnerability arises from incorrect verifier pruning in the Berkeley Packet Filter (BPF), leading to unsafe code paths being incorrectly marked as safe. The vulnerability has a CVSS v3.1 Base Score of 8.8, indicating its high severity. The consequences are arbitrary read/write in kernel memory, lateral privilege escalation and container escape.

This is the second instalment of a two-part blog post. The blogs are based on one of our “AppSec Talk” YouTube videos, featuring Kondukto Security Advisor Ben Strozykowski and Rami McCarthy, a seasoned security engineer with experience at Figma and Cedar Cares. In that video, Ben and Rami delved into the critical role developers play in the security program and the application security lifecycle.

Application Programming Interfaces (APIs) have become the backbone of modern applications. They enable seamless interaction between different software systems, allowing businesses to innovate rapidly. With the proliferation of APIs comes an increased risk of security vulnerabilities. Ensuring API security is crucial to safeguarding sensitive data, maintaining user trust and protecting the integrity of applications.

Historically, security programs have struggled when they fail to include developers and partner teams, often falling into the trap of focusing solely on the security team’s needs. This approach has led to a disconnect between security and development teams, resulting in ineffective vulnerability management and often strained relationships.

The shift towards a proactive cybersecurity mindset has been steadily gaining momentum. Industry experts have emphasized the importance of best practices for implementation and the role of security orchestration. By integrating modern threat intelligence solutions into vulnerability management platforms, forward-thinking enterprises can become more proactive in their fight against cyber threats.

In this blog, we are going to take a closer look at the concept of Fuzzing, using Go, and how to integrate it into your CI/CD pipeline. As a quick primer, Fuzzing is an automated testing technique that involves feeding random, unexpected, or invalid data to a program or API to uncover bugs and vulnerabilities. The core idea is to expose the program to inputs that developers may not have anticipated, thereby revealing flaws such as crashes, memory leaks, and security vulnerabilities.