devopsy.kinsta.cloud

Tag: appsec

Mend.io Adds Tool to Detect Presence of Generative AI Code

Mend.io this week added a MendAI tool to its application security portfolio that identifies code generated by an artificial intelligence (AI) model.

In addition, the Mend.io software composition analysis (SCA) tool has been expanded to surface detailed AI model versioning and update information for every AI model used, including outdated dependencies.

Mend.io has indexed more than 35,000 publicly available, pre-trained large language models (LLMs) to identify which AI models are being employed.

Jeffery Martin, vice president of product for Mend.io, said that capability makes it simpler for organizations to navigate licensing, compatibility and compliance issues within the context of a software bill of materials (SBOM). That’s a critical capability as organizations look to apply governance policies to code generated by AI platforms, he added.

It’s still early days as far as usage of AI to generate code is concerned. However, it’s clear data science teams relying on machine learning operations (MLOps) workflows to build models will need access to the same types of SCA and SBOM tools that many developers routinely use today. Less clear is to what degree DevSecOps teams will meld workflows to unify the management of application and AI model security, he added.

Unfortunately, data science teams typically don’t have a lot of cybersecurity expertise. That’s problematic because as AI applications are developed using tools and platforms that have known vulnerabilities, it becomes relatively trivial for cybercriminals to exploit them. As such, DevSecOps teams that have deployed AI applications will need tools that enable them to identify which potentially vulnerable code generated by an AI model is running where in an application environment.

Cybercriminals Commonly and Specifically Target AI Models

Unfortunately, cybercriminals are now aware of these vulnerabilities so it’s becoming increasingly common to see malware campaigns specifically targeting AI models. The purpose of those attacks can range from simply exfiltrating data, to poisoning the pool of data being used to train AI models that are rapidly becoming the most valuable software asset an organization can own. The challenge is that data science teams may need to replace an entire AI model to remediate those vulnerabilities because many AI models are not as easily patched as other software artifacts.

It’s not apparent yet who within organizations will ultimately assume responsibility for AI application security. The challenge is there is already a general shortage of cybersecurity expertise and the number of existing cybersecurity professionals that have AI expertise is extremely limited. Undoubtedly, it will eventually require organizations to meld MLOps and cybersecurity workflows to define a set of best MLSecOps practices.

In the meantime, DevOps teams should expect the amount of code running in their application environments that might have been generated by an AI model to increase substantially. With or without permission, many developers are reusing code generated by AI platforms, most of which have been trained using code of uneven quality collected from across the internet. As a result, the code generated by the AI model might be just as flawed as the code used to train the AI model.

Regardless of how that code was created, however, the one certain thing is that a DevSecOps team will be expected to address any subsequent application security issues that will almost inevitably arise.

June 14, 2024
DevSecOps: 5 Tips for Developing Better, Safer Apps

The cloud is rapidly becoming a major battleground for cyberattacks — and the cost of a breach has never been higher. According to IBM, the average cost of a breach was $4.5 million, and according to the CrowdStrike 2023 Global Threat Report, there was a 95% increase in cloud exploits in 2022, with a three-fold increase in cases involving cloud-conscious threat actors. The acceleration of cloud-focused threat activity and its effects has made security a key priority across organizations – especially DevOps teams.

Security in the Cloud is a Shared Responsibility

Security teams are accountable for protecting against risks but cannot be the only ones. Each team must try to communicate why their part of the development lifecycle is important to the other teams in the pipeline. With the growth of cloud-native applications and the demand for faster application delivery or continuous integration/continuous delivery (CI/CD), the use of containers is increasing widely. Complex security issues arise as businesses adopt containerized and serverless technologies and cloud-based services.

Application developers have a tricky balance to maintain between speed and security. In DevOps, security used to be an issue addressed after development — but that’s changing. Now, developers who previously had to code right up to the last minute — leaving almost no time to find and fix vulnerabilities — are using shift-left capabilities to ensure that code with security vulnerabilities is not moved into production.

When security is considered at every step in the pipeline, it ensures developers find and address issues early on and reduces the cost of downstream fixes. DevSecOps helps developers find and remediate vulnerabilities earlier in the app development process. Vulnerabilities discovered and addressed during development are less expensive and faster to fix. Automation of testing, remediation and delivery ensures stronger software security without slowing development cycles. The goal is to make security a part of the software development workflow, instead of having to address more issues during runtime.

Below are five key tips for developing apps with security and efficiency.

1. Automate Security Reviews and Testing.

Every DevSecOps pipeline should utilize a combination or variation of tools and features like those listed below. A good automated and unified solution will provide broad visibility and address those issues as they arise, while alerting, enforcing compliance and providing customized reports with relevant insights for the DevOps and security teams.

SAST: Static application security testing to detect insecure code before it’s used

SCA: Software composition analysis to detect library vulnerabilities before building

CSA: Container scanning analysis to detect operating system library vulnerabilities and mitigate risk

IaC scanning: Infrastructure-as-code scanning to detect vulnerabilities in infrastructure

ASPM: Application security posture management to detect application vulnerabilities and risks once deployed

2. Integrate With Developer Toolchains.

Streamline and consolidate your toolchain so developers and security teams can focus attention on a single interface and source of truth. The tighter the integration between security and app development, the earlier threats can be identified, and the faster delivery can be accelerated. Seamlessly integrate with Jenkins, Jira, Bamboo, GitLab and other cloud security solutions to allow DevOps teams to respond to and remediate incidents faster within the toolsets they already use.

3. Share Security Knowledge Among Teams.

DevSecOps is a journey enabled by technology but a process that starts with people. Your DevSecOps team should share lessons learned and mitigation steps after resolving the compromise. Some organizations even assign a security champion who helps introduce this sense of responsibility for security within the team. Be prepared to get your teams on board before changing the process, and ensure everyone understands the benefits of DevSecOps. Make security testing part of your project kickoffs and charters, and empower your teams with training, education and tools to make their jobs easier.

4. Measure Your Security Posture.

Identify the software development pain points and security risks, create a plan that works well for your organization and your team, and drive execution. Ensure you track and measure results such as the time lost in dealing with vulnerabilities after code is merged. Then, look for patterns in the type or cause of those vulnerabilities, and make adjustments to detect and address them earlier. This introduces a shared plan with integration into the build and production phases.

5. “Shift Right” as well as “Shift Left.”

Detection doesn’t always guarantee security. Shifting right and knowing how secure your applications and APIs are in production is just as important. By leveraging ASPM to uncover potential vulnerabilities in the application code once they are up and deployed, teams can find potential exposure in their application code that could allow backdoor access to other critical data and systems.

The bottom line is that while security and development used to be separate, the lines are now blurring to a point where security is becoming more integrated with the day-to-day job of developers. The benefit is that the modern practice brings together teams across the company to a common understanding, which drives business growth. DevSecOps requires teams to collaborate and enable the organization to deliver safer applications to customers without compromising security.

Security is not meant to be a red light on the road to your business goals or slow down your software development. It is to enable you to reach those goals safely with minimal risk.

March 21, 2024
Cycode Brings Generative AI to App Security Posture Management

Cycode today added generative artificial intelligence (AI) capabilities to its application security posture management (ASPM) platform to make it simpler for DevSecOps teams to identify the root cause of vulnerabilities in complex distributed computing environments.

At the same time, Cycode is adding plugins for VS Code and JetBrains integrated development environments, a command line interface and pull request scanners to make it easier to identify security issues as early as possible during the software development life cycle (SDLC). Cycode also revealed today it now has more than 75 connectors to various security tools commonly used within DevSecOps workflows.

Amir Kazemi, director of product marketing for Cycode, said the company is using OpenAI’s generative AI platform to provide a natural language interface for invoking the Risk Intelligence Graph that is at the core of the Cycode ASPM platform. As part of that effort, Cycode is now also making available an Executive Dashboard that, based on all the dependencies uncovered, provides summaries of risks that make it easier to discern what is occurring across an application environment.

The platform, as a result, can now provide automated risk scoring for vulnerabilities based on actual severity and potential impact to the business, said Kazemi. The overall goal is to make it simpler to secure software supply chains by facilitating the proactive collaboration between application developers, DevOps engineers and cybersecurity professionals, he added.

It’s not clear what impact generative AI is going to have on how DevSecOps workflows are constructed, but making it easier to identify the root cause of security issues in application environments made up of monolithic applications, microservices and event-driven frameworks is now essential. Application security has simply become too chaotic to effectively manage without help from AI, noted Kazemi. In its current state, application security is simply unmanageable, he added.

The challenge is that just because a zero-day vulnerability has been discovered, it doesn’t always follow that application development teams know where every instance of it exists within their application environment. It’s not uncommon for DevSecOps teams to discover outdated versions of components that have known vulnerabilities to be running months after a patch in an updated version of that component has been made available.

DevSecOps teams are, of course, always trying to strike a balance between the level of threat a vulnerability represents and the possibility that the patch that should be applied might break an application. However, given the risk to application environments, it’s becoming less risky to patch an application than it is to hope that cybercriminals don’t exploit a known vulnerability.

While much DevSecOps progress has been made in recent years, it’s clear there is still much work to be done. Hopefully, generative AI will make it simpler for application development teams to address issues more rapidly than ever. In the meantime, however, DevSecOps teams should assume cybercriminals are looking to exploit the same AI capabilities to discover vulnerabilities they can exploit faster than ever.

February 21, 2024
Squaring the Circle: How to Make Public APIs Private
APIs have become an integral part of enabling seamless data exchange and functionality between systems and businesses. In fact, APIs are trebling every year. Public APIs are, by their nature, designed to be open and discoverable. By definition, this also means that APIs are open to attacks from the networks. This is why APIs have become the number one attack vector.

APIs becoming the top attack vector makes sense. All our other business apps are hidden behind private networks–usually MPLS (AWS Direct Connect, Azure ExpressRoute, etc.), VPN or zero-trust network access (ZTNA). But APIs are exposed to the public Internet.

Day 2 API Security Solutions and Snowflakes

This network exposure is why there are so many ‘Day 2′ API security solutions – WAFs, API security platforms, IDS, etc. These solutions do a great job of blocking threats that have already been identified, yet there are successful API attacks each day. Why?

Each API is unique and evolves rapidly–constant changes in business logic, authentication, authorization and configurations. APIs are snowflakes. The result is that many API attacks are effectively zero-day attacks–novel attacks that exploit recent and unique changes to specific APIs.

A Difficult Race to Win

Network exposure and snowflake characteristics are why API-related vulnerabilities multiply each day.

The ‘snowflake’ issue means many attacks are unknown to the Day 2 solutions – they attack vulnerabilities that didn’t previously exist. So, after the novel attack, we race to apply a fix. Who are we racing against? Every attacker on the internet. The API is public–exposed to the networks–not like our other business apps, which are private behind an MPLS, VPN or zero-trust solution. Racing against attackers on the internet is difficult–and coming second may result in a service outage, data breach or customer compromise.

Why Not Avoid the Race?

So why not make the APIs private, avoid exposing them to the internet, put them behind MPLS, VPN or ZTNA, like we do for all our other business apps? API clients are too distributed and dynamic; there is no good way to manage agents or dedicated circuits across all those API clients. Those solutions were not made for APIs–it is like fitting a square peg in a round hole.

Zero-Trust API Networking Needs to be Built for APIs

To make our APIs private like the rest of our business apps, we must first meet the business need. API providers need to achieve the business velocity and agility they require. On the technical side, we need a secure networking solution which is built to manage the distribution of the API clients, and assume that there will always be snowflake-like vulnerabilities.

Let’s look at an open source solution for zero trust APIs which is purpose-built for those business, technical and operational requirements:

There are usually three reactions to the diagram above:
1. OK, tell me how it works. See below.
2. Looks complex. Nope. All software, spun up in minutes, centrally managed.
3. Seems like a proprietary solution for users accessing their applications. Yes! It uses principles similar to the user-to-app zero-trust world but secures APIs.
How Zero-Trust API Networking Works

Here are the four pillars of zero-trust API networking:
1. Eliminate public access. Your API clients will use private IPs or domains to reach your APIs. If your company name is Acme, then your clients might now use api7.acme.unreachable (you make up any domain you want). Envision an attacker trying to interrogate *.acme.unreachable to find snowflake vulnerabilities. Not possible because it is not a public domain—your API server is no longer reachable.
2. Identity, authentication, authorization, mutual TLS. Authorized API clients do need to access your APIs from the internet. Your zero-trust API overlay network is accessed from the internet only with X.509-certificate cryptographically authenticated identities, continuous authentication and least privileged access authorization via mTLS links. You move the policy enforcement point (PEP) from your DMZ to your API clients. Your API clients add a few lines of zero-trust networking code to enable this model. This code replaces VPNs, MPLS, etc. (there are non-code options too). For example, some of your API clients likely use Resty, a popular open source REST client library for Golang. Their existing Resty code adds a few lines of zero-trust API networking code:
3. Outbound-only. You eliminated the inbound access. Your server will instead open identified, authenticated and authorized sockets to your zero-trust API overlay network (you’ll close all your inbound ports and only enable outbound ports to specific overlay network router IPs or to your x.acme.unreachable domain).
4. Management. API networking security is not very valuable without simple management. The zero-trust API overlay cloud is software-only and cloud-native. You spin up your private API clouds in minutes, anywhere, without deploying hardware. If an API client is compromised, one click or automated action removes its access. Network usage for each client/API is in your web console or management dashboard.
The above is based on the open source OpenZiti zero-trust networking platform, but any zero-trust API platform should provide similar functionality. Specifically, it should enable:
- Speed. Securing APIs but slowing down business or complicating operations is not the trade-off most organizations want. Security and speed is the goal.
- Minimize the threat surface. Close all inbound ports in front of your API servers. Use private, unreachable addresses or domains to minimize your attack surface and stop racing against network-based attackers.
- Extensibility. Software-only, cloud-native architectures. Preferably open source based.
- Operations excellence. Centralized visibility, controls, policies and identities. Rich telemetry data. Performance-optimized overlay networks.
- Zero-trust security. Identity-based networking, continuous authentication, strong authorization, mutual TLS (mTLS), encrypted delivery, microsegmentation.
- Flexibility. API clients add a few lines of code to get zero-trust API networking. Other API clients use API-specific agents or DNS to access the overlay, if desired, while your API server/gateway is still private.
- Recovery. Assume breaches. Implement microsegmentation, prevent data exfiltration and provide simple controls to immediately remove threats.
Zero-Trust API Networking

While APIs will always be snowflakes, they no longer need to be our only business app that is exposed to the networks. By minimizing the attack surface, without compromising business velocity and API client experience, we can finally mitigate against our greatest API security risk. This also simplifies our day two API security, the solutions that inspect API queries after they enter our DMZ.

Rather than trying to filter the internet, day two solutions can focus on detecting authorized API clients that may have been compromised. Similarly, our operations teams are freed to focus on sessions from authorized API clients rather than wading through oceans of data from port scanning, DDoS attacks, unauthorized API queries and attempts to interrogate public APIs to find new snowflake vulnerabilities.
February 14, 2024
Snyk Acquires Helios to Extend Reach of ASPM Platform

With its acquisition of Helios, Snyk plans to add an ability to capture application runtime data to extend the capabilities of its application security posture management (ASPM) platform.

Manoj Nair, chief product officer for Snyk, said Snyk AppRisk will soon provide real-time insights into runtime environments using a Helios observability platform that provides them with deeper insights into issues that need to be resolved. That capability will provide developers with additional context as more responsibility for application security continues to shift left toward application development teams, he added.

Armed with that insight, it then becomes simpler to prioritize remediation efforts based on the level of risk a vulnerability actually represents to the organization, said Nair. That’s critical to close a longstanding divide between cybersecurity and application development teams that, in the absence of any real ability to determine the severity of a vulnerability, results in developers wasting what limited time they have to allocate to remediation, he noted.

Nair said the overall goal is to enable organizations to deploy more secure applications while minimizing adverse impacts on developer productivity.

Snyk last year acquired Enso Security to add an ASPM platform to its portfolio that serves as the foundation upon which Snyk AppRisk was built. It also includes Insights, a Snyk tool that makes use of multiple types of artificial intelligence (AI) models to identify, prioritize and fix vulnerabilities.

There’s often not a lot of love lost between cybersecurity teams and application developers who typically don’t have a lot of cybersecurity expertise. Most of the issues that cybersecurity teams are tasked to address start with mistakes made by developers that cybersecurity teams then need to convince developers to allocate time to fix.

Thanks to the rise of DevSecOps best practices, the overall security of software supply chains is improving, but there is still a long way to go before application security truly improves. The one thing that is certain is the level of accountability for vulnerabilities is only going to rise as more stringent regulations go into effect in the months and years ahead.

In the meantime, DevSecOps teams should assume there will be many more vulnerabilities to remediate. Developers are increasingly using generative AI tools to write code. The challenge is general-purpose large language models (LLMs), such as the one used to drive ChatGPT, were trained using examples of code of varying quality collected from across the web. A lot of the code these platforms generate, not surprisingly, contains vulnerabilities that many developers will not immediately recognize without the aid of some type of scanning tool.

At the same time, cybercriminals are becoming more efficient at discovering and exploiting vulnerabilities that exist in applications that have already been deployed in production environments. DevSecOps teams should expect that, as a result, more zero-day vulnerabilities requiring immediate attention will soon be discovered.

One way or another, the percentage of time allocated to application security issues is only going to increase. The only thing left to determine is how best to go about reducing the time and effort needed to make applications as secure as possible.

January 29, 2024
Survey: Widespread Inability to Remediate App Vulnerabilities

A survey of 621 IT and security professionals published this week found only 20% are confident in their ability to detect a vulnerability before an application is released.

Conducted by the Ponemon Institute on behalf of Security Journey, a provider of cybersecurity training services for developers, the survey finds 61% struggling to remediate vulnerabilities effectively, with 55% blaming misalignment between development, security and compliance teams for delays.

A third of respondents (33%) said teams lacked a common view of applications and assets, with 38% acknowledging they lack the ability to hold departments accountable for patching applications. Only 11% of organizations believed they patch vulnerabilities effectively in a timely manner, the survey finds.

In the 12 months prior to the study, 54% of respondents suffered a security incident due to an unpatched vulnerability, with 51% experiencing more than eight incidents.

Overall, half (50%) admitted they fail to test the security of their applications after they have been released. Only 36% specifically teach developers to write secure code. Just one-fifth (21%) educated developers on vulnerability remediation. Less than half (43%) have invested in training provided by a third party.

When training is provided, 68% of respondents also admitted immediate feedback is not provided and less than half (47%) said secure coding training is customized to meet developer needs. Half (50%) of those who provided training have no formal assessment to measure knowledge gain, the survey found.

Amy Baker, chief marketing officer and security education evangelist for Security Journey, said the survey makes it clear much work still needs to be done in terms of teaching developers how to write secure code.

In addition, too many software development teams are overly optimistic about their ability to remediate known vulnerabilities the next time they plan to update an application, said Baker. Many developers move on to the next application simply because either the pressure to meet delivery deadlines is too intense or there is some other emerging technology, such as large language models (LLMs), that needs to be learned, she added. In fact, too many organizations are far too focused on the rate at which applications are built and deployed at the expense of cybersecurity, Baker noted.

That’s especially problematic because cybercriminals have become much more adept at monitoring application deployments and updates, she added.

The amount of time between when code is deployed and when cybercriminals begin scanning it for vulnerabilities is now measured in hours rather than days. Developers, unfortunately, are deploying more insecure code than ever. In fact, much of that code is insecure by design, noted Baker.

Overall, nearly half of respondents (48%) only train developers annually, bi-annually or when an incident occurs. More than two-thirds (68%) only train developers on how to implement secure coding practices to meet compliance requirements. In effect, because developers are not taught security in school, what training they do receive is on the job, said Baker.

Clearly, there is still much work to be done when it comes to implementing DevSecOps best practices to improve application security. In the meantime, the amount of code that needs to be patched has already reached proportions that most application development teams are never going to be able to effectively address.

January 24, 2024
Backslash ASPM Platform Prioritizes DevSecOps Efforts

Backslash this week made generally available a namesake application security posture management (ASPM) platform that identifies and prioritizes vulnerabilities based on how easy they are to exploit and reach.

Backslash CEO Shahar Man said the goal is to provide a comprehensive approach to providing a vulnerability exploitability exchange (VEX) platform integrated with tools for software composition analysis (SCA), static application security testing (SAST), secrets detection and creating software bills of materials (SBOMs).

That approach makes it possible to visually model threats within the context of the actual application architecture, noted Man. Armed with those insights, it then becomes possible to address cybersecurity issues by pinpointing the lines of code impacted and also identifying the developer who wrote that code.

While there is a pressing need to improve application security, current DevSecOps workflows are inefficient because there is simply too much noise, said Man. Development teams are inundated with alerts that lack any meaningful context, so after a while, they simply start to ignore them, he added.

In addition, cybersecurity teams will often create a spreadsheet with a long list of vulnerabilities to be addressed without knowing whether the code impacted is accessible via the internet or whether the code that might be affected is actually running in a production environment, said Man.

Other issues may involve transitive dependencies in open source software that developers might not even be able to address without the maintainers of those projects providing a patch.

Streamlining DevSecOps workflows has become crucial in an era where organizations are about to be held much more accountable for the security of the applications being deployed. Today, development teams are lucky if they can allocate 10% of their time to remediate vulnerabilities. Organizations need to be certain that time is spent addressing issues that could have the most impact on the business. Otherwise, a level of fatigue sets in the results in developers making the same cybersecurity mistakes time and again, noted Man.

The Backslash platform, on average, identifies one critical toxic flow for every 100 security alerts produced by other tools, he added. Once critical issues are identified, it becomes possible to more effectively apply the limited resources available to improve the overall state of application security in a meaningful way.

The debate, in the meantime, over how far left to shift responsibility for application security continues. In theory, developers are in the best position to remediate issues, but most of them have limited cybersecurity expertise. DevSecOps teams are generally going to be in a better position to identify which issues need to be addressed based on the severity of the risk they might represent. Otherwise, it’s probable IT teams will wind up wasting their time fixing issues while others that might lead to a major breach or blithely ignored.

Regardless of the approach to DevSecOps, the need for a common framework of understanding is crucial if the cultural divide between development teams and cybersecurity professionals that has existed for decades is ever going to be effectively bridged.

November 3, 2023
Steady On. We Still Have a Job to Do

It is all the rage to talk about how significantly large language models (LLMs) and generative AI will change every niche and corner of IT. And change IT it will. But the hype cycle is at its highest right now, and I’d caution against getting too worked up about it. We’re in for a few interesting years, and the spaces I cover (DevOps and security—with a more application-centric perspective but with ops experience) are definitely going to benefit from the various AI bits being worked in. All testing—including AppSec, but all testing—will benefit both in test generation and results analysis/filtering. In fact, I’ll go ahead and say that the question in testing will no longer be, “How much time to we have to devote to it?” and will rapidly become “How many systems’ resources do we have to dedicate to it?” It will still be a long process—AI isn’t speeding up the cumulative time it takes to run thorough testing (be it functional or security). It will make that the bottleneck though, because test generation will at least be LLM-assisted, and will eventually become completely generative AI-created while at the same time, results will get more and more filtering and analysis. A minor result here plus a minor result there will automatically be detected as an extended vulnerability. There are a ton of other possibilities, but these two seem pretty obvious when I look across the testing technology space. More testing and better results analysis are on the horizon—without requiring more staff. Of course, you can do so much more, which would require the organization to add staff to follow up on results, but that’s nothing new; testing finds issues that are interruptive and take man-hours to fix—we all know of bits in the application portfolio that we should probably fix but that aren’t high enough priority to do so, for example. But fixing is different than finding. I have seen demos in security scanners that offer auto-fix options for developers. Run the test during CI, create a ticket and let the developer see suggested code rework right in the IDE. It is early days for this, but if you look, you can find vendors doing it. And that’s really rather cool.

But we’ve all heard the “this changes everything” storyline over and over. 4GLs, XML, Java and JavaScript were all going to eliminate developers. In fact, they all created more developers. AI has a better chance of actually removing parts of our workload than any of these technologies did, but we’re still in “watch and wait” mode. It seems obvious that grunt coding will fall to LLMs … And aside from keeping staff trained to manage source, that is a good thing. We use open source, modules and libraries to do much the same thing today. I see this as equivalent to entry-level writing jobs. We’ll have to transform from the current model, but the current entry level development model wasn’t ideal anyway, so lets make a better one. Testing capabilities will be greatly enhanced, but testing of all kinds was so far behind new code generation at most orgs that the impact will be all positive as testing catches up. AI-based test generation today can generate thousands of permutations for a given piece of code, and analyze the results to just have analysts look at the truly disconcerting or confusing test results. And the question will become, “How many servers do we want to dedicate to run this?” Which is different, but just means we have more tests running to make a more solid and/or secure product and environment.

So, in summary, is change coming? Yes. And that is not significantly different than the last couple decades where change has become IT’s constant companion. For most of you, the way you do your job today is not the same as the way you did it even two years ago. ML/GAI/LLMs are just another iteration. The apps still have to be built, deployed and maintained. So until HAL comes along, keep kicking it. You’re keeping it together, and who knows what the future brings.

September 6, 2023
Snyk Survey: AI Generating More Vulnerabilities in Code

A survey of 404 IT professionals conducted by Snyk found the use of artificial intelligence (AI) to write code is creating a security paradox. On one hand, just over three-quarters of respondents (77%) said AI tools improve code security. At the same time, however, 59% are concerned that AI tools trained using general-purpose large language models (LLMs) will introduce security vulnerabilities that first appeared in the code used to train them.

The challenge with general-purpose LLMs is that they are trained using a combination of excellent, mediocre and flawed code. As a result, any recommendation surfaced has the potential to be a suboptimal security result.

Randall Degges, head of developer relations for Snyk, said that as AI tools increase the velocity at which applications can be constructed, it’s probable that DevOps teams will discover more vulnerabilities in their code.

In general, 61% of respondents also noted that automation has increased the number of false positives, with 62% of respondents reporting that at least one out of every four vulnerability alerts they received from automation tools were false positives. Well over a third (35%) said false positives represented over half of the vulnerability alerts.

On the plus side, however, more organizations are paying closer attention to application security issues in the wake of several high-profile breaches of software supply chains and disclosures of vulnerabilities. A full 96% reported their organizations are addressing supply chain security problems on an ad hoc basis, yet only half have a formalized supply chain security strategy in place.

The survey also finds 87% of respondents work for organizations impacted by a software supply chain security issue in the last year, with 61% having implemented new tools and processes as a result.

A total of 62% of respondents work for organizations that have a software life cycle assurance process in place, but only 42% of organizations are using software bills of materials (SBOMs). In addition, only 40% have formal security ratings for the open source packages that developers employ, and 31% ignore risks that arise from indirect dependencies.

However, only 40% of organizations have embedded security testing tools into their integrated development environments (IDEs), with 40% not using software composition analysis (SCA) or static application security testing (SAST) tools at all. In fact, even though 80% of respondents reported working for organizations that ship code daily, only 27% claim to continuously audit their code.

As a result, many vulnerabilities remain unpatched, with Java (42%) and JavaScript (31%) topping the list in terms of code with the most ignored vulnerabilities.

Finally, the survey also noted that vulnerabilities involving open source code are now being remediated faster than proprietary code. Maintainers of open source software are now paying more attention to cybersecurity issues thanks in part to the tools and best practices provided by the Open Source Security Foundation (OpenSSF), said Degges.

There will, of course, come a day when AI is more widely used to analyze vulnerabilities in code. In effect, AI will be used to solve some of the security issues general-purpose LLMs create. In the meantime, however, DevSecOps teams would be well-advised to proceed with caution.

July 28, 2023
New Relic Adds App Security Testing Tool to Observability Platform

New Relic today made available a public preview of an application security testing tool that will be integrated into its observability platform.

Esteban Gutierrez, CISO and vice president of information security for New Relic, said the New Relic Interactive Application Security Testing (IAST) will provide DevSecOps teams with the context needed to identify the root cause of a cybersecurity issue down to specific lines of code.

DevSecOps teams will be able to take advantage of IAST to identify vulnerabilities both in code as it is written and after it has been deployed in a production environment without any false positives, he noted.

New Relic achieves that goal using deterministic testing techniques that surface an actual proof-of-exploit using observability data collected from both applications and the underlying infrastructure upon which they depend, said Gutierrez. DevSecOps teams are then provided with guided remediation suggestions, guardrails and tracking tools to both remediate the issue at hand and prevent it from reoccurring, he noted.

New Relic IAST takes advantage of the agent software New Relic provides to collect observability data, which reduces the total cost of DevSecOps by providing IT teams that have adopted the New Relic platform with an integrated set of application security testing tools that doesn’t require them to acquire and manage a separate additional platform, added Gutierrez.

That approach also ensures that application security testing is integrated with the continuous integration/continuous delivery (CI/CD) platforms that New Relic already observes, he added.

The reason most vulnerabilities are not remediated in a timely fashion is the DevOps teams responsible for creating and deploying the required patches lack any context. They often don’t know, for example, how many instances of a vulnerability there might be or the actual level of severity. Without those insights, it becomes exceedingly difficult to prioritize remediation efforts, noted Guttierrez.

As application security requirements become more stringent in the wake of forthcoming legislation, it’s now more of a question of when than if organizations will be required to better secure their software supply chains. The issue DevOps teams face now is finding a way to integrate application security testing tools into existing DevOps workflows without slowing down the pace at which applications are being developed.

Of course, not every vulnerability discovered requires the same level of attention. Depending on its severity and likelihood of being exploited, DevOps teams need to prioritize which vulnerabilities need to be remediated first. There simply are not enough resources available today to fix every vulnerability an application might have. For the foreseeable future, there will remain technical debt involving vulnerabilities that will need to be addressed after an application is deployed in a production environment.

The issue, of course, is that cybercriminals are getting more adept at exploiting those vulnerabilities. The amount of time any DevOps team has to resolve issues before they result in a breach continues to dwindle.

July 26, 2023