DevSecOps | Breaking Cybersecurity News | The Hacker News

What is Continuous Attack Surface Penetration Testing or CASPT? Continuous Penetration Testing or Continuous Attack Surface Penetration Testing (CASPT) is an advanced security practice that involves the continuous, automated, and ongoing penetration testing services of an organization's digital assets to identify and mitigate security vulnerabilities. CASPT is designed for enterprises with an evolving attack surface where periodic pentesting is no longer sufficient. Unlike traditional penetration testing, which is often performed annually or semi-annually, CASPT is an ongoing process that integrates directly into the software development lifecycle (SDLC), ensuring that vulnerabilities are discovered and addressed in real-time or near-real-time. CASPT is a proactive security measure designed to stay ahead of potential attackers by continuously evaluating the security posture of an organization. It enables security teams to identify critical entry points that could be exploited b

The heightened regulatory and legal pressure on software-producing organizations to secure their supply chains and ensure the integrity of their software should come as no surprise. In the last several years, the software supply chain has become an increasingly attractive target for attackers who see opportunities to force-multiply their attacks by orders of magnitude. For example, look no further than 2021's Log4j breach, where Log4j (an open-source logging framework maintained by Apache and used in a myriad of different applications) was the root of exploits that put thousands of systems at risk.  Log4j's communication functionality was vulnerable and thus provided an opening for an attacker to inject malicious code into the logs which could then be executed on the system. After its discovery, security researchers saw millions of attempted exploits, many of which turned into successful denial-of-service (DoS) attacks. According to some of the latest research by Gartner, close t

Social media accounts help shape a brand's identity and reputation. These public forums engage directly with customers as they are a hub to connect, share content and answer questions. However, despite the high profile role these accounts have, many organizations overlook social media account security. Many lack the safeguards to prevent unauthorized access — a situation no organization wants as it can quickly spiral to include reputational damage and financial losses.  With the impact this high, the need for deep understanding of social media risks as well as how to protect an organization's social media account are more crucial than ever. This article dives into the details of social media accounts, how social media can be misused and how to protect oneself. Understanding the Layers of Social Media Access Platforms like Facebook, Instagram, and LinkedIn typically have two layers of access.  The Public Facing Page : where brands post content and engage with users.  The Advertis

Introduction The Colonial Pipeline ransomware attack (2021) and SolarWinds supply chain attack (2020) were pivotal moments in cybersecurity, starting a new challenge for Chief Information Security Officers ( CISOs ). These attacks highlighted the importance of collaboration between CISOs and DevOps teams to ensure proper cloud security configurations. In this article, we will outline the 6-step approach to fostering strong partnerships between CISOs, DevOps teams, IT management, and organizations that can help to drive innovation while maintaining a robust security posture. You will learn how a CISO can effectively communicate with IT leadership and what methods to try. Our narrative will emphasize the most crucial aspect of an organization's security - growing your strong security team and moving to a proactive approach.  Understanding such breaches, such as the Capital One data breach (2019), Epsilon data breach (2019), Magecart compromises (ongoing), and MongoDB breaches (2

One of the enduring challenges of building modern applications is to make them more secure without disrupting high-velocity DevOps processes or degrading the developer experience. Today's cyber threat landscape is rife with sophisticated attacks aimed at all different parts of the software supply chain and the urgency for software-producing organizations to adopt DevSecOps practices that deeply integrate security throughout the software development life cycle has never been greater.  However, HOW organizations go about it is of critical importance. For example, locking down the development platform, instituting exhaustive code reviews, and enforcing heavyweight approval processes may improve the security posture of pipelines and code, but don't count on applications teams to operate fluidly enough to innovate. The same goes for application security testing; uncovering a mountain of vulnerabilities does little good if developers have inadequate time or guidance to fix them. At a high

New cybersecurity research has found that command-line interface (CLI) tools from Amazon Web Services (AWS) and Google Cloud can expose sensitive credentials in build logs, posing significant risks to organizations. The vulnerability has been codenamed  LeakyCLI  by cloud security firm Orca. "Some commands on Azure CLI, AWS CLI, and Google Cloud CLI can expose sensitive information in the form of environment variables, which can be collected by adversaries when published by tools such as GitHub Actions," security researcher Roi Nisimi  said  in a report shared with The Hacker News. Microsoft has since  addressed  the issue as part of security updates released in November 2023, assigned it the CVE identifier CVE-2023-36052 (CVSS score: 8.6). The idea, in a nutshell, has to do with how the CLI commands such as could be used to show (pre-)defined environment variables and output to Continuous Integration and Continuous Deployment (CI/CD) logs. A list of such commands spann

Identities now transcend human boundaries. Within each line of code and every API call lies a non-human identity. These entities act as programmatic access keys, enabling authentication and facilitating interactions among systems and services, which are essential for every API call, database query, or storage account access. As we depend on multi-factor authentication and passwords to safeguard human identities, a pressing question arises: How do we guarantee the security and integrity of these non-human counterparts? How do we authenticate, authorize, and regulate access for entities devoid of life but crucial for the functioning of critical systems? Let's break it down. The challenge Imagine a cloud-native application as a bustling metropolis of tiny neighborhoods known as microservices, all neatly packed into containers. These microservices function akin to diligent worker bees, each diligently performing its designated task, be it processing data, verifying credentials, or

GitLab once again released fixes to address a critical security flaw in its Community Edition (CE) and Enterprise Edition (EE) that could be exploited to write arbitrary files while creating a  workspace . Tracked as  CVE-2024-0402 , the vulnerability has a CVSS score of 9.9 out of a maximum of 10. "An issue has been discovered in GitLab CE/EE affecting all versions from 16.0 prior to 16.5.8, 16.6 prior to 16.6.6, 16.7 prior to 16.7.4, and 16.8 prior to 16.8.1 which allows an authenticated user to write files to arbitrary locations on the GitLab server while creating a workspace," GitLab  said  in an advisory released on January 25, 2024. The company also noted patches for the bug have been backported to 16.5.8, 16.6.6, 16.7.4, and 16.8.1. Also resolved by GitLab are four medium-severity flaws that could lead to a regular expression denial-of-service (ReDoS), HTML injection, and the disclosure of a user's public email address via the tags RSS feed. The latest updat

GitLab has released security updates to address two critical vulnerabilities, including one that could be exploited to take over accounts without requiring any user interaction. Tracked as  CVE-2023-7028 , the flaw has been awarded the maximum severity of 10.0 on the CVSS scoring system and could facilitate account takeover by sending password reset emails to an unverified email address. The DevSecOps platform said the vulnerability is the result of a bug in the email verification process, which allowed users to reset their password through a secondary email address. It affects all self-managed instances of GitLab Community Edition (CE) and Enterprise Edition (EE) using the below versions - 16.1 prior to 16.1.6 16.2 prior to 16.2.9 16.3 prior to 16.3.7 16.4 prior to 16.4.5 16.5 prior to 16.5.6 16.6 prior to 16.6.4 16.7 prior to 16.7.2 GitLab said it addressed the issue in GitLab versions 16.5.6, 16.6.4, and 16.7.2, in addition to backporting the fix to versions 16.1.6, 1

Picture this: you stumble upon a concealed secret within your company's source code. Instantly, a wave of panic hits as you grasp the possible consequences. This one hidden secret has the power to pave the way for unauthorized entry, data breaches, and a damaged reputation. Understanding the secret is just the beginning; swift and resolute action becomes imperative. However, lacking the necessary context, you're left pondering the optimal steps to take. What's the right path forward in this situation? Secrets management is an essential aspect of any organization's security strategy. In a world where breaches are increasingly common, managing sensitive information such as API keys, credentials, and tokens can make all the difference. Secret scanners play a role in identifying exposed secrets within source code, but they have one significant limitation:  they don't provide context. And without context, it's impossible to devise an appropriate response plan. Con