DevSecOps | Breaking Cybersecurity News | The Hacker News

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

Introduction The infamous  Colonial   pipeline ransomware attack (2021) and  SolarWinds  supply chain attack (2020) were more than data leaks; they were seismic shifts in cybersecurity. These attacks exposed a critical challenge for Chief Information Security Officers ( CISOs ): holding their ground while maintaining control over cloud security in the accelerating world of DevOps. The problem was emphasized by the  Capital One   data breach (2019),  Epsilon   data breach (2019),  Magecart   compromises (ongoing), and  MongoDB  breaches (2023-), where hackers exploited a misconfigured AWS S3 bucket. Strong collaboration between CISOs and DevOps teams on proper cloud security configurations could have prevented the breaches. More than the fight against hackers and the consequences of their attacks, several important problems stand out —the evolution of CISO's role and responsibilities and the challenge of improving cloud security, and how security operations teams collaborate with bus

As a vCISO, you are responsible for your client's cybersecurity strategy and risk governance. This incorporates multiple disciplines, from research to execution to reporting. Recently, we published a comprehensive playbook for vCISOs, "Your First 100 Days as a vCISO – 5 Steps to Success" , which covers all the phases entailed in launching a successful vCISO engagement, along with recommended actions to take, and step-by-step examples.  Following the success of the playbook and the requests that have come in from the MSP/MSSP community, we decided to drill down into specific parts of vCISO reporting and provide more color and examples. In this article, we focus on how to create compelling narratives within a report, which has a significant impact on the overall MSP/MSSP value proposition.  This article brings the highlights of a recent guided workshop we held, covering what makes a successful report and how it can be used to enhance engagement with your cyber security clients.

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

John Hanley of IBM Security shares 4 key findings from the highly acclaimed annual Cost of a Data Breach Report 2023 What is the IBM Cost of a Data Breach Report? The IBM Cost of a Data Breach Report is an annual report that provides organizations with quantifiable information about the financial impacts of breaches. With this data, they can make data driven decisions about how they implement security in their organization. The report is conducted by the Ponemon Institute and sponsored, analyzed, and published by IBM Security. In 2023, the 18th year the report was published, the report analyzed 553 breaches across 16 countries and 17 industries. According to Etay Maor, Senior Director of Security Strategy at  Cato Networks , "We tend to talk a lot about security issues and solutions. This report puts a number behind threats and solutions and provides a lot of information to support claims of how a threat actor, a solution or a process impacts you financially." Key Finding #1: The