secure coding | 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

Imagine a world where the software that powers your favorite apps, secures your online transactions, and keeps your digital life could be outsmarted and taken over by a cleverly disguised piece of code. This isn't a plot from the latest cyber-thriller; it's actually been a reality for years now. How this will change – in a positive or negative direction – as artificial intelligence (AI) takes on a larger role in software development is one of the big uncertainties related to this brave new world. In an era where AI promises to revolutionize how we live and work, the conversation about its security implications cannot be sidelined. As we increasingly rely on AI for tasks ranging from mundane to mission-critical, the question is no longer just, "Can AI  boost cybersecurity ?" (sure!), but also "Can AI  be hacked? " (yes!), "Can one use AI  to hack? " (of course!), and "Will AI  produce secure software ?" (well…). This thought leadership article is about the latter. Cydrill  (a

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

Web Application Security consists of a myriad of security controls that ensure that a web application: Functions as expected. Cannot be exploited to operate out of bounds. Cannot initiate operations that it is not supposed to do. Web Applications have become ubiquitous after the expansion of Web 2.0, which Social Media Platforms, E-Commerce websites, and email clients saturating the internet spaces in recent years.  As the applications consume and store even more sensitive and comprehensive data, they become an ever more appealing target for attackers.  Common Attack Methods The three most common vulnerabilities that exist in this space are Injections (SQL, Remote Code), Cryptographic Failures (previously sensitive data exposure), and Broken Access Control (BAC). Today, we will focus on Injections and Broken Access Control.  Injections  SQL is the most common Database software that is used, and hosts a plethora of payment data, PII data, and internal business records. A SQ

While the use of Infrastructure as Code (IaC) has gained significant popularity as organizations embrace cloud computing and DevOps practices, the speed and flexibility that IaC provides can also introduce the potential for misconfigurations and security vulnerabilities.  IaC allows organizations to define and manage their infrastructure using machine-readable configuration files, which are typically version-controlled and treated as code. IaC misconfigurations are mistakes, or oversights, in the configuration of infrastructure resources and environments that happen when using IaC tools and frameworks. Discover the power of a comprehensive AppSec platform. Download this new whitepaper to discover how to effortlessly integrate application security into every stage of the software development life cycle. Learn about the role of integration and automation, the 7 requirements for choosing an AppSec platform, and how Checkmarx One™ simplifies security. Misconfigurations in IaC ca

GitHub has announced the general availability of a new security feature called  push protection , which aims to prevent developers from inadvertently leaking keys and other secrets in their code. The Microsoft-owned cloud-based repository hosting platform, which began  testing the feature  a year ago, said it's also extending push protection to all public repositories at no extra cost. The functionality is designed to work hand-in-hand with the existing  secret scanning feature , which scans repositories for known secret formats to prevent their fraudulent use and avert potentially serious consequences. "Push protection prevents secret leaks without compromising the developer experience by scanning for highly identifiable secrets before they are committed," GitHub  said  earlier this week. "When a secret is detected in code, developers are prompted directly in their IDE or command line interface with remediation guidance to ensure that the secret is never expo

Professional developers want to do the right thing, but in terms of security, they are rarely set up for success. Organizations must support their upskilling with precision training and incentives if they want secure software from the ground up. The cyber threat landscape grows more complex by the day, with our data widely considered highly desirable "digital gold". Attackers are constantly scanning networks for vulnerable applications, programs, cloud instances, and the latest flavor of the month is APIs, with Gartner  correctly predicting  that they would become the most common attack vector in 2022, and that is in no small part thanks to their often lax security controls.  Threat actors are so persistent that new apps can sometimes be compromised and exploited within hours of deployment. The  Verizon 2022 Data Breach Investigations Report  reveals that errors and misconfigurations were the cause of 13% of breaches, with the human element responsible overall for 82% of the 23,000

How much time do developers spend actually writing code? According to recent studies , developers spend more time maintaining, testing and securing existing code than they do writing or improving code. Security vulnerabilities have a bad habit of popping up during the software development process, only to surface after an application has been deployed. The disappointing part is that many of these security flaws and bugs could have been resolved in an earlier stage and there are proper methods and tools to uncover them. How much time does a developer spend on learning to write a functioning code? And how much is spent on learning about code security? Or learning how not to code?" Wouldn't it be better to eradicate the problem from the system rather than having it there, and then trying to detect and stop an ongoing attack targeting it? You can test your secure coding skills with this short  self-assessment. The true cost of bugs Everyone makes mistakes, even developers.

Now more than ever, organizations need to enable their development teams to build and grow their security skills. Today organizations face a threat landscape where individuals, well-financed syndicates, and state actors are actively trying to exploit errors in software. Yet, according to recent global research, 67% of developers that were interviewed said they were still shipping code they knew contained vulnerabilities.  Helping your development teams progress to achieve security maturity is possible, and ultimately beneficial. It will help ensure secure software development at every stage of the software development lifecycle. But how can you help your development teams reach security maturity? We dug deep and leveraged insights from over 400 of our customers to identify traits and behaviors that occur when a development team increases its security maturity. Here we share two of them: #1: A deep understanding of your gaps Before creating any maturity program, we first need to u

Python has its pros and cons, but it's nonetheless used extensively. For example, Python is frequently used in data crunching tasks even when there are more appropriate languages to choose from. Why? Well, Python is relatively easy to learn. Someone with a science background can pick up Python much more quickly than, say, C. However, Python's inherent approachability also creates a couple of problems. Whenever Python is updated, it means a big refactoring workload, which often gets dealt with poorly – or not at all. That leads to poor performance and security vulnerabilities. But maybe there is a better way: a tool to keep your Python tasks running smoothly and securely day in, day out. Let's take a look. It's slow, but it does the job Python isn't the fastest language around, but despite its comparative disadvantages, you'll often see it used for intensive data crunching operations. Think machine learning, computer vision, or even pure math in high-perform

Progress powers technology forward. But progress also has a cost: by adding new capabilities and features, the developer community is constantly adjusting the building blocks. That includes the fundamental languages used to code technology solutions. When the building blocks change, the code behind the technology solution must change too. It's a challenging and time-consuming exercise that drains resources. But what if there's an alternative? The problem: reading code someone else wrote Let's take a step back and take a look at one of the fundamental challenges in development: editing someone else's code. Editing code you just wrote, or wrote a couple of weeks ago, is just fine. But editing your own code written years ago – never mind someone else's code - that's a different story. In-house code style rules can help but there are always odd naming conventions for variables and functions, or unusual choices for algorithms. Arguably, a programmer's abilit

The developers who create the software, applications and programs that drive digital business have become the lifeblood of many organizations. Most modern businesses would not be able to (profitably) function, without competitive applications and programs, or without 24-hour access to their websites and other infrastructure. And yet, these very same touchpoints are also often the gateway that hackers and other nefarious users employ in order to steal information, launch attacks and springboard to other criminal activities such as fraud and ransomware.  Successful attacks remain prevalent, even though spending on cybersecurity in most organizations is way up, and even though movements  like DevSecOps  are shifting security towards those developers who are the lifeblood of business today. Developers understand the importance of security, and overwhelmingly want to deploy secure and quality code, but software vulnerabilities continue to be exploited.  Why? For the 2nd year, Secure Co

Professional developers want to embrace DevSecOps and write secure code, but their organizations need to support this seachange if they want that effort to grow. The cyber threat landscape is becoming more complex by the day. Attackers are constantly scanning networks for vulnerable applications, programs, cloud instances, and the latest flavor of the month is APIs, widely considered an easy win thanks to their often lax security controls. They are so persistent that new apps can sometimes be compromised and exploited within hours of deployment. The Verizon 2021 Data Breach Investigations Report makes it very clear that the threats leveled against businesses and organizations  are more dangerous  today than at any other point in history. It's becoming very clear that the only way to truly fortify the software being created is to ensure that it's built on secure code. In other words, the best way to stop the threat actor invasion is to deny them a foothold into your applications in