DevSecOps | Breaking Cybersecurity News | The Hacker News

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

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

Validate security continuously across your full stack with Pen Testing as a Service. In today's modern security operations center (SOC), it's a battle between the defenders and the cybercriminals. Both are using tools and expertise – however, the cybercriminals have the element of surprise on their side, and a host of tactics, techniques, and procedures (TTPs) that have evolved. These external threat actors have now been further emboldened in the era of AI with open-source tools like ChatGPT. With the potential of an attack leading to a breach within minutes, CISOs now are looking to prepare all systems and assets for cyber resilience and rapid response when needed. With tools and capabilities to validate security continuously – including penetration testing as a service – DevSecOps teams can remediate critical vulnerabilities fast due to the easy access to tactical support to the teams that need it the most. This gives the SOC and DevOps teams tools to that remove false po

As cloud applications are built, tested and updated, they wind their way through an ever-complex series of different tools and teams. Across hundreds or even thousands of technologies that make up the patchwork quilt of development and cloud environments, security processes are all too often applied in only the final phases of software development.  Placing security at the very end of the production pipeline puts both devs and security on the back foot. Developers want to build and ship secure apps; security teams want to support this process by strengthening application security. However, today's security processes are legacy approaches that once worked brilliantly for the tight constraints of on-prem production, but struggle in ever-shifting cloud environments. As a result, security is an afterthought, and any attempt to squeeze siloed security into agile SDLC can  swell the cost of patching by 600% . A new cloud security operating model is long overdue. Shift-left is an appro

APIs, more formally known as application programming interfaces, empower apps and microservices to communicate and share data. However, this level of connectivity doesn't come without major risks. Hackers can exploit vulnerabilities in APIs to gain unauthorized access to sensitive data or even take control of the entire system. Therefore, it's essential to have a robust API security posture to protect your organization from potential threats. What is API posture management? API posture management refers to the process of monitoring and managing the security posture of your APIs. It involves identifying potential vulnerabilities and misconfigurations that could be exploited by attackers, and taking the necessary steps to remediate them. Posture management also helps organizations classify sensitive data and ensure that it's compliant with the leading data compliance regulations such as GDPR, HIPAA, and PCI DSS.  As mentioned above, APIs are a popular target for attackers

If you're involved in securing the applications your organization develops, there is no question that Static Application Security Testing (SAST) solutions are an important part of a comprehensive application security strategy. SAST secures software, supports business more securely, cuts down on costs, reduces risk, and speeds time to development, delivery, and deployment of mission-critical applications.  SAST scans code early during development, so your AppSec team won't be scrambling to fix unexpected vulnerabilities right before that big launch is planned. You'll avoid surprises and launch delays without inadvertently releasing risky software to customers — or into production.  But if you consider SAST as a part of a larger AppSec platform, crucial for those who wish to  shift security everywhere  possible in the software development life cycle (SDLC), some SAST solutions outshine others.  Knowing what to focus on With a plethora of players in the market, sometimes

In the fast-paced cybersecurity landscape, product security takes center stage. DevSecOps swoops in, seamlessly merging security practices into DevOps, empowering teams to tackle challenges. Let's dive into DevSecOps and explore how collaboration can give your team the edge to fight cyber villains. Application security and product security Regrettably, application security teams often intervene late in the development process. They maintain the security level of exposed software, ensuring the integrity and confidentiality of consumed or produced data. They focus on securing data flows, isolating environments with firewalls, and implementing strong user authentication and access control. Product security teams aim to guarantee the intrinsic reliability of applications. They recommend tools and resources, making them available to developers and operations. In the DevSecOps approach, each team is responsible for the security of the applications they create. These teams apply secur