There's never enough time or staff to scan code repositories. To avoid dependency confusion attacks, use automated CI/CD tools to make fixes in hard-to-manage software dependencies.

Software dependencies, or a piece of software that an application requires to function, are notoriously difficult to manage and constitute a major software supply chain risk. If you're not aware of what's in your software supply chain, an upstream vulnerability in one of your dependencies can be fatal.

A simple React-based Web application can have upward of 1,700 transitive NodeJS "npm" dependencies, and after a few months "npm audit" will reveal that a relatively large number of those dependencies have security vulnerabilities. The case is similar for Python, Rust, and every other programming language with a package manager.

I like to think of dependencies as decaying fruit in the unrefrigerated section of the code grocer, _especially_ npm packages, which are often written by unpaid developers who have little motivation to put in more than the bare minimum of effort. They're often written for personal use and they're open sourced by chance, not by choice. They're not written to last.

    

NodeJS dependencies, highly vulnerable, live in production! I took this from an actual, production React-Native application found on GitHub.

Recently (as of the writing of this article), PyTorch, one of the top two most popular machine learning libraries for Python, was compromised for five days via its dependency "torchitron." The attacker was able to collect system information and steal 1,000 files from each affected user's home directory. In 2021, Log4j was famously compromised and because it was bundled into basically every Web-facing Java project, DevSecOps teams were under a lot of pressure to identify where exactly they were vulnerable.

    

Too many dependencies to reliably keep track of, even if most are "mostly" secure.

Even 20 _intentional_ dependencies are too many for a development team to continually audit, much less 2,000 _transitive ones_.

**What's Been Done So Far?**

Not all hope is lost. For _known_ (reported and accepted) vulnerabilities, tools exist, such as pip-audit, which scans a developer's Python working environment for vulnerabilities. Npm-audit does the same for nodeJS packages. Similar tools exist for every major programming language and, in fact, Google recently released OSV-Scanner, which attempts to be a Swiss Army knife for software dependency vulnerabilities. Whether developers are encouraged (or forced) to run these audits regularly is beyond the scope of this analysis, as is whether they actually take action to _remediate_ these known vulnerabilities.

However, luckily for all of us, automated CI/CD tools like Dependabot exist to make these fixes as painless as possible. These tools will continually scan your code repositories for out-of-date packages and automatically submit a pull request (PR) to fix them. Searching for "dependabot\[bot\]" or "renovate\[bot\]" on GitHub and filtering to active PRs yields millions of results! However, 3 million dependency fixes versus hundreds of millions of active PRs at any given time is an impossible quantification to attempt to make outside of an in-depth analysis.

**State of the Art Isn't Quite Good Enough**

You need to keep in mind that these auditing tools do nothing to protect developers against zero-day exploits or N-days that were reported but have yet to be officially accepted. In the case of the PyTorch vulnerability previously mentioned, none of the auditing tools would have caught this _class_ of dependency vulnerability, because there was no traditional "software vulnerability" being exploited. These "dependency confusion" attacks take advantage of the fact that package managers look to their "default" repository before checking other repositories that dependencies may select for _their_ dependencies. In the case of PyTorch, the "torchitron" dependency was self-hosted by the PyTorch Foundation. When the attacker uploaded their version to PyPI, it took precedence over the official version.

How long will this continue? Forever. If there is value in exploiting these vulnerabilities, attackers will continue to take advantage of them. Luckily, in the case of PyTorch, "only" data exfiltration took place. Future victims might not be so lucky, however. A sophisticated attacker only needs one successful attempt at access to remain persistent in a victim's system (and network).

**What Does This Mean for Me?**

Did you install your packages from the command line? If so, did you type them in properly? Now that you've installed your dependencies "correctly," did you verify that the code for each dependency does exactly what you think it does? Did you verify that each dependency was installed from the expected package repository? Did you ….

Probably not, and that's OK! It's inhumane to expect developers to do this for every single dependency. The best bet for software developers, software companies, and even individual tinkerers is to have some form of runtime protection/detection. Luckily for us all, there are detection and response tools that have relatively recently been created which are now part of a healthy and competitive ecosystem! Many of them, like Falco, Sysdig Open Source, and Osquery, even have free and open source components. Most even come with a default set of rules/protections.

On Shaky Ground: Why Dependencies Will Be Your Downfall

The cloud-native application protection platform market is expanding as security teams look to protect their applications and the software supply chain.

As more organizations shift to cloud-native application development to support new business features and digital transformation initiatives, software supply chain issues have become more visible. Because cloud-native development relies so heavily on open source software, organizations have to start thinking about the components that go into these applications.

To build these cloud-native applications, developers have adopted agile application development practices and rapid release cycles, and they rely heavily on open source code and microservices from a widely distributed and often vast community to compose their containers and serverless functions. While the source code may primarily come from an established ecosystem, it is common for some to originate from unknown sources or obsolete projects.

Traditional security approaches aren't designed to handle this new approach to application development, especially for modern cloud compute and serverless architectures. This is the area cloud-native application protection platforms evolved to address. Gartner describes CNAPP as "an integrated set of security and compliance capabilities designed to help secure and protect cloud-native applications across development and production."

According to a recent Frost & Sullivan report, sales of CNAPP topped $1.7 billion in 2021, nearly 49% higher than 2020. Frost & Sullivan projects that CNAPP revenues will grow at a compound annual growth rate of almost 26% from 2021 to 2026. The report's author, industry principal for global cybersecurity Anh Tien Vu, forecasts that by 2026, revenues will exceed $5.4 billion "because of the increasing demand for a unified cloud security platform that strengthens cloud infrastructure security and protects applications and data throughout their life cycle."

**Prevent Problems During Development**

Attackers are increasingly homing in on cloud-native targets to exploit vulnerabilities that enter the software supply chain. Last year, the Log4Shell vulnerability in the widely deployed Log4j Java runtime library illustrated the broad impact such a vulnerability can have on the application ecosystem. Given the widespread distributed deployment of Java applications, organizations had to scramble to find and patch them after Apache Foundation's public disclosure.

"With Log4j, people didn't know whether those libraries were in use or not," says Enterprise Strategy Group senior analyst Melinda Marks. Experts frequently cite Log4j as a wake-up call to CISOs and CIOs that software development lifecycles need to collaborate more closely and shift left.

Marks says CNAPP enables organizations to establish DevSecOps processes in which software developers take the lead in discovering potential flaws in code before deploying application runtimes into production, but it also goes further. "This is important for preventing security issues before you deploy your applications to the cloud, because once you deploy them, they're available for the hackers," Marks says.

**Monitor Runtime to Identify Priorities**

CNAPPs consolidate siloed capabilities, including the scanning of development artifacts such as containers and infrastructure as code (IaC), cloud security posture management (CSPM), cloud infrastructure management (CIEM), and runtime cloud workload protection platforms. Besides providing a more unified approach and better visibility of the risk of cloud-native computing environments, CNAPP provides common controls to mitigate vulnerabilities.

Notably, CNAPP also facilitates collaboration among application development, cybersecurity, and IT infrastructure teams, paving the way for detecting and mitigating vulnerabilities before applications are deployed into production. Security vendors such as Check Point and Palo Alto Networks are adding CNAPP capabilities to their security platforms.

Marks warns that there's a misconception about shifting security left: that it's all about moving security up front in the software development and build cycles. "There's also the need to tie in the runtime monitoring and have that context for developer workflows, so they're not wasting time on fixing things that have no impact on how the application is actually going to run in the cloud," she says.

Tackling Software Supply Chain Issues With CNAPP

CloudNativeSecurityCon North America 2023 was a vendor-neutral cloud-native security conference. Here's why it was important.

Cloud-native technology is growing in importance, and the Cloud Native Computing Foundation (CNCF), part of the Linux Foundation, is a key organization driving collaboration on cloud security throughout the industry.

That collaboration includes events such as KubeCon Americas and Europe, which often feature cloud-native security as a key topic, but seeing the importance of cloud native security, CNCF took the next step and created a separate event.

CloudNativeSecurityCon North America 2023 (CNSC) recently took place in Seattle, and served as the first vendor-neutral, practitioner-driven conference focused exclusively on cloud-native security. The event featured over 800 attendees and 50 sponsors. It had 70-plus sessions for all security levels of technologists.

**Security Is People-Powered; Industry Collaboration Is a Solution**

Security remains a pressing issue for the cloud-native and open source community, said Priyanka Sharma, Executive Director, CNCF. During her keynote, she said there are 7.1 million-plus cloud-native developers according to Slash Data.

She emphasized that the industry needs "a paradigm shift to level up our performance," as cloud usage will continue to grow, and so will the threats related to it.

Though the organizations are doing their part to secure their cloud environments, Sharma indicated that top-down approach may not be the best way, instead having a more bottom-up approach from the community, pointing to software security vendor Snyk's "2022 State of Cloud Security Report," which showed 77% of organizations saw poor training and collaboration as a major cloud security challenge.

    

Source: CNSC

Having siloed teams working in different countries, using different tools, and counting on unmonitored policies are common security challenges in many enterprise security scenarios, but when they involve the cloud, it multiplies difficulties to the security environment further. Hence, Sharma stated, "Security is people-powered," and having industry-level collaboration from all the stakeholders along with a shared asset directory will improve cloud security across the industry. Even after all the talks about innovation and right approach done in the cloud-native space, a skill shortage is something the industry is still facing. CNCF announced Kubernetes and Cloud Associate (KCSA) certification, to address the biggest challenge of lack of technical expertise in cloud-native environment.

CNCF organizes itself with Technical Advisory Groups (TAGs) for different focus areas, and it is looking to a Security TAG to help organizations with facilitating the security for projects across the cloud-native ecosystem. It's a 165-member team that supports CNCF projects through education, partnership, and project engagement. This group will help with security features for any CNCF projects; any incubating project within the organization must now go through a security audit by the Security TAG. The Sigstore project that was adopted by Kubernetes was an example of such open, multivendor collaboration.

**Key Conference Topics**

Themes that popped up during the event — including SBOM, runtime security, infrastructure as-a-code security, code to secure policies and authentication, and ChatGPT — indicated that the adoption of cloud-native applications will continue to grow, and the industry must prioritize security for these applications. The thought of having an open source security tool for securing open source code makes sense. Today, CNCF has 21 security-related open-source projects: Open Policy Agent (OPA) and Update Framework TUF have graduated with five other incubating projects, and the rest are in the sandbox stage.

**Software Supply Chain Security**

    

Source: CNSC

Many sessions at the conference were focused on understanding what the software supply chain means and why securing it remains important.

A talk by a Yahoo representative highlighted how 85% to 97% of enterprise code uses open source components, and any vulnerabilities in these may pose security threats. That issue underscores the importance of having security ingrained at every stage of the software development life cycle (SDLC), from application development to CI/CD pipeline down to production.

Code dependencies have become one of the most common reasons leading to supply chain attacks. According to a recent report on software supply chain security, supply chain attacks have grown 742% year-over-year in the past three years. Therefore, a DevSecOps approach is important to ensure the DevOps workflow is maintained by making security seamless. It means having security as an intrinsic part of application development, integration, and operation in DevOps-centric environments.

**"Shift Right" Is as Important as "Shift Left"**

Deployment of applications in the cloud has been a fast-track initiative for many enterprises, often in support of digital transformation initiatives, but many of the same security challenges, such as software vulnerabilities, managing configuration and permission, compliance, and detecting and responding to threats, plaguing traditional applications also hamper cloud application security.

From the cloud-native point of view, two trends are most visible. The first is the way in which "shift left" corresponds to the usage of CI/CD security, having centralized responsibilities and dependencies that can be monitored. It points to moving security toward an earlier stage in the software development life cycle, namely that security is built in from the time the source code is created.

But the second trend is "shift right," which is gaining equal importance in understanding what is going on in the runtime environment as the workload deployed on microservices and orchestrated by Kubernetes. The Falco project with CNCF (originally started by Sysdig), which is based on eBPF technology, seeks to help organizations understand what every process is doing in its containers and hosts. It is like a security camera for the cloud environment.

**Software Bill of Materials**

Log4j was a top of mind during the show, highlighting how it disrupted the operations of many organizations in so many different ways.

Similar high-profile attacks on the supply chain were the reason for the US federal government to issue an executive order to create guidelines for securing software solutions used for the government. The change of approach to building software using third-party dependencies makes having full transparency in the application important.

So, the approach of maintaining a software bill of materials (SBOM) that will offer a listing all components, modules, and libraries used in the application and also drawing the relationship between supply chain components is becoming increasingly important.

One interesting exchange during the conference tackled how to handle metadata that will be collected over time by each software element. In a panel, a Google representative mentioned its new product, Graph for Understanding Artifact Composition (GUAC), which functions like an aggregator for this metadata in a high-fidelity graph database.

**Sponsor Landscape**

    

Source: Omdia

CNSC was a relatively small-scale conference, but its sponsors represented vendors distributed across the industry. Approximately 55% were security vendors, 18% technology vendors offering some security, 12% were technology vendors that use in-house security product but do not sell the security product as a stand-alone offering, and 15% non-security vendors.

**A Strong Start**

The first-ever CNSC was a strong start for the cloud-native community to create a place to gather each year for a focused look at security challenges and opportunities in cloud-native environments.

CNCF is doing a great job getting different types of vendors together and supporting cloud-native security projects. This is exposing developers to security concerns. On the contrary, traditional security teams also must learn to work better with developers and ensure security approaches align with development priorities and business objectives.

This is just a first step toward solving the problems related to cloud-native security. There is more collaboration with people and process to be done in future.

Top Takeaways From CloudNativeSecurityCon 2023

Potential Insertion of Sensitive Information into Jetty Log Files in multiple versions of OpenNMS Meridian and Horizon could allow disclosure of usernames and passwords if the logging level is set to debug. Users should upgrade to Meridian 2023.1.0 or newer, or Horizon 31.0.4. Meridian and Horizon installation instructions state that they are intended for installation within an organization's private networks and should not be directly accessible from the Internet.

**Have a question about this project?** Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Pick a username

Email Address

Password

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CVE-2023-0815: NMS-15305: Update log4j config file by mershad-manesh · Pull Request #5741 · OpenNMS/opennms

ThingsBoard 3.4.1 could allow a remote attacker to gain elevated privileges because hard-coded service credentials (usable for privilege escalation) are stored in an insecure format. (To read this stored data, the attacker needs access to the application server or its source code.)

CVE-2023-26462: ThingsBoard Release Notes

Open source software dependencies are affecting the software security of different industries in different ways, with mature industries becoming more selective in their open source usage.

The proportion of open source codebases with vulnerabilities has continued to remain level over the past two years, but the number of applications with high-risk vulnerabilities has dropped to its lowest level in four years.

That's according to the "2023 Open Source Security and Risk Analysis" (OSSRA) report, published by Synopsys on Feb. 22. The annual study, based on audits of more than 1,700 applications, found that almost every software program (96%) included some kind of open source software component, with the average codebase consisting of 76% open source code. While the number of codebases with at least one vulnerability remained mostly stable over the past three years at slightly more than 80% — 84% in 2022 — the number of applications with high-risk vulnerabilities has dropped to about half (48%) of all applications tested, from a peak of about 60% in 2020.

Overall, the data shows some bright spots in the struggle against vulnerable dependencies, of which the average application has 595, but there's no broad trend toward greater application security, says Mike McGuire, a senior software solutions manager at Synopsys Software Integrity Group.

"Organizations are struggling to keep up with the scale of open source usage," he says. "If you take those almost 600 components per application on average, and multiply that by the number of vulnerabilities that are disclosed on an annual basis, then you can really, really start to drown in the work."

    

Overall open source usage remained mostly level, as did overall vulnerable codebases. Source: Synopsys

Open source components, and the dependencies on which popular application frameworks rely, continue to pose security problems for software makers and application developers. The ubiquity of some components — such as Log4j in the Java ecosystem — continues to cause security issues for many applications based on open source frameworks.

**Outdated Dependencies Are Common**

Applications that include a lot of components — and by extension, those components' dependencies — can have deep dependency trees that make it hard to find every vulnerability. Nearly all applications (91%), for example, included at least one open source component that has no development in the past two years, a likely sign that the project is no longer being maintained and, therefore, represents a security risk.

Nearly one in eight applications also had more than 10 different versions of a specific codebase, with each likely imported from a different component and that component's dependencies.

Failing to eliminate those older codebases represents a risk, Synopsys stated in the OSSRA report.

"Open source was in nearly everything we examined this year; it made up the majority of the codebases across industries, and it contained troublingly high numbers of known vulnerabilities that organizations had failed to patch, leaving them vulnerable to exploit," the report stated. "It is crucial to understand that while open source itself does not pose any inherent level of risk, failing to manage it does."

Whether more dependencies means more vulnerabilities is still a relationship under investigation. JavaScript frameworks, for example, tend to have the greatest number of dependencies, but JavaScript applications tend to be less vulnerable than Java and .NET applications, according to a report released by software-security firm Veracode in January.

**Don't Fall Behind With Open Source Dependencies**

The impact of open source code on security varies by industry, according to the OSSRA report. Some industries have increased their open source usage, while others have consolidated their portfolio. Depending on their level of maturity, the impact on security can be different.

Education technology companies, for example, have adopted open source components to drive new features and applications required by schools during the push for online teaching during the pandemic. In that industry, open source software accounted for more than 80% of codebases in 2022, up from about a third in 2018. Other sectors also saw dramatic, if not so stark, increases in usage. The aerospace, aviation, automotive, transportation, and logistics sector, for example, also nearly doubled its usage of open source components over five years.

The significant increase in adoption has led to many companies losing visibility into what is making up their software and what needs patching, McGuire says.

"More organizations are using more open source components, but they just don't have the programs in place to track those \[patches\] down," he says. "Once you get underwater with those updates — it's just like any other technical debt or debt in general, right? — it's really tough to claw your way back."

Other industries have reduced their usage of open source software, likely by consolidating on fewer projects as dependencies, according to the report. Both the Internet and software infrastructure sector, and the telecommunications and wireless sector, have reduced the contribution of open source software to their codebases to under 60%. Both industries also saw fewer high-severity vulnerabilities.

Half of Apps Have High-Risk Vulnerabilities Due to Open Source

Despite increased threats, an uncertain economy, and increasing automation, your organization can still thrive.

When the vulnerability in Log4j happened, security teams sought the answer to a seemingly simple question: Am I vulnerable?

Answering that question led to a maelstrom of activity. Security groups requested information from vendors about their level of vulnerability and, in turn, had to respond to their customers about whether they were vulnerable. In many ways, the entire exercise seemed more about legal obligations than making people more secure.

The deluge of information — some of it useful, some of it useless — highlighted the need to rethink how we are doing security in the future.

We're living in a chaotic time. With a possible recession, technology companies trimming their ranks, and businesses pushing further into the cloud and adopting more automation and AI, security teams need to re-evaluate. Do they just follow the traditional playbook without thinking why? Or do they improve what they are doing to make security better?

Here are some focus areas to reduce chaos and increase overall security effectiveness.

**Simplify for Greater Visibility**

Gaining visibility into your applications and infrastructure is essential. Companies expanding their use of the cloud and converting applications to cloud-native infrastructure often see initial growing complexity because of a period of redundancy and hybrid infrastructure.

Pushing beyond that stage provides both cost and security benefits. Limiting the use of third-party tools to capture and analyze data for security teams is important. There's really no reason to, say, pull NetFlow data off the cloud infrastructure, when that same data — and more — is natively available.

Explore your cloud service provider's tools. Major cloud providers will often provide you detailed data, and you can reduce the complexity of the infrastructure needed to analyze that data.

**Pay Attention to Even the "Small" Breaches**

When NASA astronauts start getting emails in French, it's time to investigate.

That's what happened to Gavin early in his security career. Turns out two students in France were using Telnet to get into the NASA server and using it to send email. The incident ended up driving a greater project around making sure NASA had a robust data classification system and better data isolation.

Weird anomalies can be signs of an attack, but they can also drive a security team to better understand their organization's infrastructure. Investigations are time consuming but also often worthwhile, so even the small stuff should be investigated.

**Threat Intelligence Can Help**

Usually, a security team's most precious commodity is time. The old method of analyzing every IT project (even as they are changing) and looking for security issues is untenable.

Threat intelligence can help cut through the noise. By using threat intelligence, your security team can take a priority-based approach to architecture based on real-world attack intelligence. At the same time, they can deprioritize other areas. Threat intelligence can also help refine your playbooks and increase the maturity of your security team.

**Thriving With Automation, Planning for Layoffs**

Security teams are facing other sorts of stress, with most economists expecting a recession. Security teams still need to be able to perform, despite stressors and even in the face of losing some of their headcount.

To focus on the most important aspects of security, even with fewer people, companies need to adopt more automation, machine learning, and artificial intelligence. Every team should be asking how to speed up manual tasks with automation. Automation, correctly applied, can free up staff to be working on the areas.

In the past, security teams have been considered a roadblock — a bump on the way to a company's core business of making money. Most teams have moved past the reflexive need to say no. We're here to make sure that the business is taking educated risks, but at the end of the day, just saying no to everything doesn't help anyone.

As every security manager surveys the horizon, they need to look at how they have traditionally approached problems. And they should consider whether now is time to say yes to something new.

Headwinds Don't Have to Be a Drag on Your Security Effectiveness

Only 10% of corporate executives expect to lay off members of cybersecurity teams in 2023, much lower than other areas, as companies protect hard-to-find skill sets.

Cybersecurity professionals will likely weather an economic downturn better than most other workers, as corporate executives worry that a recession could bring an increase in cyberattacks and acknowledge the difficulty in hiring knowledgeable workers, according to a new study by (ISC)2, a cybersecurity certification group.

The survey of 1,000 nontechnical C-level business leaders found that companies are more likely to cut employees in human resources, finance, and operations, and least likely to cut in cybersecurity, IT, and operations.

The reasons are pretty clear: 87% of executives thought a reduction in their cybersecurity team would increase their business risk, and 80% believed that economic troubles will lead to more cyber threats.

The results suggest that even non-technical executives have increased the priority of cybersecurity, says Clar Rosso, CEO of (ISC)2.

"In the workforce study every year, we're talking to cybersecurity professionals, so we know what they think," she says. "Now we see that organizational leaders are saying that \[cybersecurity professionals\] are on the bottom of our list to cut, and they're on the top of our list if we need to hire back."

Economists still widely expect a recession in 2023, despite strong job data and the Federal Reserve's continued efforts to increase interest rates and reduce money supply. In December, a Bloomberg poll showed economists predicted a 70% chance of a recession, and in January, a Wall Street Journal poll of economists suggested a 61% chance of a recession.

    

Cybersecurity has the least likelihood of suffering staff cuts in 2023. Source: (ISC)2

Yet, with annual inflation remaining above 4% for the past 22 months, companies have already started taking steps to prepare for an economic downturn, including staff reductions. In the cybersecurity industry, for example, more than 55 vendors have already laid off workers, according to Layoffs.fyi.

**Cybersecurity Gigs Are Resilient**

The (ISC)2 survey suggests that most layoffs are not cybersecurity or IT jobs, but administration and support. In cybersecurity, only 31% of companies expect to reduce their cybersecurity workforce if the economy declines, while 51% will prioritize reinvestment in cybersecurity if the economy improves, according to the survey.

The spread between the two sentiments is the highest for cybersecurity among all business units, with IT teams coming in second place, facing a 35% expectation of a reduction in bad times and 49% expectation of reinvestment in good times. Human resources and sales are the most at risk, with 44% and 41% of executives indicating they will lay off HR and sales staff in bad times, respectively, while 29% and 30% will prioritize the reinvestment in those departments if the economy improves.

Highlighting the pent-up demand in cybersecurity, three-quarters of executives (74%) would consider hiring cybersecurity workers laid off from other companies, the (ISC)2 survey found.

"With reports of job cuts at organizations including Twitter, Meta, Microsoft, Amazon and Google, cybersecurity staff could benefit from proactive hiring targeted towards those recent layoffs," the report stated. "With so many tech jobs impacted by recent layoffs, it is possible that many of those individuals may find opportunity in pursuing a career in cybersecurity, where they can apply related skills and expertise."

The resilience in demand for cybersecurity professionals comes as many workers burned out and resigned, part of the Great Resignation in 2022.

Organizations that lost valuable specialists did so for three main reasons, Rosso says. Cybersecurity teams have traditionally not had great career advancement opportunities, so their ability to gain promotions and increased salaries at their current company are often limited. In addition, the culture surrounding many security teams has often led to burnout and mental stress, she says.

"We know, for example, that at the end of 2021 and beginning of 2022, the Log4j issue was causing people to clock a lot of hours, and that led to some burnout," she says. "Not that cybersecurity professionals aren't always working long hours and hard, but it's just kind of a spike above and beyond."

Finally, the push to bring workers back to the office has often led people with in-demand specialties to look elsewhere.

**Cyber Threats Abound**

The resilience of cybersecurity jobs is buoyed by the constant reminders of business risks that come in the form of ransomware attacks, data breaches, and stolen intellectual property. The vast majority of executives (81%) believe that threats will increase in 2023.

The survey did not poll technical executives, such as chief technology officers (CTOs) or chief information security officers (CISOs), but gathered opinions from the nontechnical executives, such as CEOs and chief financial officers (CFOs).

"It is likely this maturing view of cybersecurity has been shaped by a continuing series of high-profile and damaging breaches," the report stated. "Security incidents have left no doubt as to the lengths threat actors will go to steal data or disrupt operations, in some cases even putting lives at risk."

In the last (ISC)2 workforce survey, the gap between available cybersecurity workers and demand shrank to 2.7 million, from 3.1 million the prior year. Many companies had closed out positions as the economy became unpredictable, leading to decelerating demand, Rosso says.

"When we were heading into 2021, our predictions were that we would see the workforce gap go up incredibly, and it actually contracted," she says. "The reason it contracted was because there was economic uncertainty, and what organizations did was they froze, or they eliminated, their open positions."

With economic growth, however, the need for cybersecurity workers will continue, she says.

Cybersecurity Jobs Remain Secure Despite Recession Fears

The startup's software helps organizations secure their containers in the cloud by teasing out which packages are running and which are vulnerable.

Oligo Security launched out of stealth on Wednesday with its runtime application security platform for detecting vulnerabilities in open source components. Oligo generates a dynamic bill of materials (BOM), identifies vulnerabilities in packages, and sets fix priorities for vulnerabilities based on application context.

Some of the most damaging cyberattacks in the past couple of years originated in open source packages included within large, complex systems. For example, Log4Shell attacks continued throughout most of 2022 because many organizations didn't even realize they were running a vulnerable version of Log4j. Oligo generates a dynamic BOM that shows all the components that are actually running, which helps establish which vulnerabilities to fix first.

Oligo profiles the legitimate behavior of each library and creates a knowledge base of libraries’ profiles. The platform fires alerts when the library activity deviates from the profile, as that would indicate suspicious activity.

"Only 15% of CVEs scanned with traditional solutions are posing a real risk, and the other 85% are irrelevant, resulting in lots of false positives and noise," Avshalom Hilu, co-founder and chief product officer of Oligo, wrote in a technical blog post. Reducing false positives and targeting mitigation more tightly can help security staff close the most dangerous flaws first and reduce alert fatigue.

The company bases its product on extended Berkeley Packet Filter (eBPF), which allows programs to run in a sandbox within the Linux operating system kernel. This means developers can extend the OS to improve visibility, networking, security, and other capabilities to make using containers in the cloud more secure.

With the dominance of cloud computing and expanding use of containerization tools like Kubernetes, eBPF is seeing traction. The overall container security market is expected to rise from $714 million in 2020 to $3.6 billion by 2026, and up to $8.2 billion by 2030. Besides Oligo, other eBPF startups in the cybersecurity space include Araali Networks, which offers an eBPF-based firewall; Cilium, an open source Kubernetes connectivity tool; Falco and Aqua, which make Kubernetes runtime security tools; and Calico, a cloud-native security company.

Oligo raised its $28 million funding from Lightspeed Venture Partners, Ballistic Ventures, and TLV Partners, along with several angel investors.

Oligo Security Takes Aim at Open Source Vulnerabilities

Possible RCE and denial-of-service issue discovered in Kafka Connect

Charlie Osborne 15 February 2023 at 14:01 UTC  
Updated: 15 February 2023 at 16:14 UTC

Possible RCE and denial-of-service issue discovered in Kafka Connect

  

Apache has resolved a vulnerability potentially exploitable to launch remote code execution (RCE) attacks using Kafka Connect.

Announced on February 8, the critical vulnerability is tracked as CVE-2023-25194. It was discovered in Apache Kafka Connect, a free, open source component of Apache Kafka that operates as a central hub for data integration between systems, databases, and key-value stores.

Apache claims that more than 80% of Fortune 100 organizations use the Kafka platform, including approximately seven out of every 10 banks.

Read more of the latest web security vulnerability news

According to Apache’s mailing list note, the security flaw was discovered by bug bounty hunter Jari Jääskelä, who reported the issue via Aiven’s HackerOne bug bounty program.

The vulnerability can only be triggered when there is access to a Kafka Connect worker – a logical work unit component – and the user must also be able to create or modify worker connectors with an arbitrary Kafka client SASL JAAS config and a SASL-based security protocol.

**Log4Shell connection**

The vulnerability involves the Lightweight Directory Access Protocol (LDAP) and Java Naming and Directory Interface (JNDI) endpoints, as was the case with ‘Log4Shell’, the landmark vulnerability discovered in ubiquitous Java logging library Apache Log4j in 2021. JNDI is also involved in another, newly disclosed critical vulnerability in Apache Sling JCR Base.

With the Kafka bug, an authenticated attacker could configure a specific connector property via either the Aiven API or the Kafka Connect REST API, forcing a worker to connect to an attacker-controlled LDAP server.

“The server will connect to the attacker’s LDAP server and it deserializes the LDAP response, which the attacker can use to execute java deserialization gadget chains on the Kafka Connect server,” the advisory reads. “Attacker\[s\] can execute commands on the server and access other resources on the network.”

When each prerequisite exists, Apache says it would be possible to perform JNDI requests, potentially leading to the execution of remote code or denial-of-service attacks.

**Disclosure**

The report was first submitted to Aiven via the organization’s bug bounty program on April 4, 2022. Triage took place in May and Jääskelä was awarded a $5,000 reward for their efforts before the issue was fixed and publicly disclosed.

Apache Kafka versions 2.3.0-3.3.2 were impacted, and the vulnerability was fixed in version 3.4.0.

The organization notes that since Kafka 3.0.0, users have been able to specify the connector configuration properties used in the attack chain. A new property has been added that disables problematic login module usage in the SASL JAAS configuration in version 3.4.0, alongside additional security measures.

Apache said: “We advise the Kafka Connect users to validate connector configurations and only allow trusted JNDI configurations. Also, examine connector dependencies for vulnerable versions and either upgrade their connectors, upgrading that specific dependency, or removing the connectors as options for remediation.”

Jääskelä also submitted a second critical vulnerability report concerning Apache Kafka in the same month.

The Aiven JDBC sink, including the SQLite JDBC driver, could be abused with an unprotected Jolokia bridge to execute RCE on Kafka Connect servers. The bug bounty hunter was awarded $5,000 for this report, and the security issue has since been resolved.

The Daily Swig has reached out to the Apache project and we will update this story as and when we hear back.

YOU MAY ALSO LIKE OAuth ‘masterclass’ crowned top web hacking technique of 2022

Tag

#log4j