devopsy.kinsta.cloud

Tag: threat intelligence

Cycode Extends DevSecOps Reach to Software Packages Developers Download

Cycode today revealed it is providing early access to an extension of its platform for securing software supply chains that prevents developers from downloading malicious or suspicious software packages onto their workstations.

A Workstation Protection capability that has been added to that platform enables DevSecOps teams to apply policies and controls that prevent developers from downloading potentially malicious instances of software packages from a software repository.

Specifically, the Cycode agentic development lifecycle (ADLC) Protection platform applies two controls in real time. The first inspects software packages against a threat intelligence feed to prevent downloads of known malicious software packages. The second will automatically prevent the download of any software package that has been too recently updated on the assumption that there has not been enough time to properly vet it, otherwise known as a cool down period.

Devin Maguire, senior product marketing manager for Cycode, said that now cybercriminals are more aggressively poisoning upstream sources of code, the need to apply controls at the workstation level has become critical. Designed to be installed as part of the Mobile Device Management module that Cycode already provides, those controls can be applied with no additional console needing to be added to an existing DevSecOps workflow based on the Cycode platform, he added.

Most application developers routinely download software components from multiple software repositories. Cybercriminals are now targeting those repositories in the hopes of injecting malware into a downstream application that they can later activate. That tactic has become even more pernicious because cybercriminals are also now starting to use malicious prompts to trick AI coding agents into downloading malicious software packages.

Unfortunately, application developers don’t always scan each package for malware before incorporating it into their codebase. Hopefully, that malware will be discovered at some point before that code is incorporated into an application running in a production environment. Cycode, however, is making a case for applying controls that prevent malicious software packages from ever entering the software supply chain in the first place, said Maguire.

Mitch Ashley, vice president and practice lead for software lifecycle engineering at The Futurum Group, said package policy is now an agent governance decision. There is no doubt coding agents increase software supply chain risks on the developer workstation, he added. When an agent installs packages on its own, install time becomes the first control point, well before a scanner sees the code, noted Ashley.

It’s not clear how aggressively DevSecOps teams are now moving to lock down software supply chains but as the number of attacks aimed at upstream repositories continues to increase it’s now more a question of how soon they will revisit those workflows. Cybersecurity teams, in particular, have become more acutely aware of the fact that the software supply chain created to build applications has become a soft underbelly that adversaries now regularly target. As such, they are asking more pointed questions about how applications are actually constructed.

Hopefully, the poisoning of the software repositories that house software packages will eventually be resolved at the source. In the meantime, it’s up to each DevSecOps team to lock down their software supply chain in a way that doesn’t wind up slowing down the pace at which applications are being built by, for example, trying to limit access to any and all software packages that were developed outside the organization.

September 23, 2026
Cloudsmith Brings Threat Intelligence to Software Artifacts

Cloudsmith this week at the KubeCon + CloudNativeCon Europe conference revealed it has added an ability to enrich packages with threat intelligence that enables DevSecOps teams to better evaluate the risk attached to downloading a software component.

Nigel Douglas, head of developer relations for Cloudsmith, said this extension to the managed service it provides for managing software artifacts makes it possible to attach data about known malware and vulnerabilities from sources such as the Open Software Security Foundation (OpenSSF) to a software package.

DevSecOps teams can also automatically evaluate a software bill of materials (SBOM) to identify and block unsafe transitive dependencies or non-compliant licenses.

The overall goal is to make it easier to create and enforce policies that prevent developers from downloading software packages that might have been compromised by a cyberattack or contain a vulnerability that could be easily exploited, noted Douglas. In fact, a Cloudsmith survey finds 44% of respondents work for organizations that have confirmed a security incident caused by a third-party dependency, with a further 39% reporting near misses.

Based on open source Open Policy Agent (OPA) software that is managed under the auspices of the Cloud Native Computing Foundation (CNCF), DevSecOps teams can, for example, automatically quarantine recently made available packages to ensure they have been vetted before being downloaded. Additionally, DevSecOps teams can now block packages that have vulnerabilities that rate highly on the Exploit Prediction Scoring System (EPSS).

When access to a software package is restricted, developers also receive custom instructions, directly in their command line interface (CLI) that provide instructions for making remediation or exception requests.

In the wake of a series of attacks on software supply chains that are becoming more common, many organizations are revisiting DevSecOps workflows to reduce risks. The issue is likely to become even more problematic as organizations rely more on AI agents to build software faster than ever, which may result in even more vulnerable code being downloaded from repositories such as GitHub.

At the same time, mandates in the European Union (EU) such as the Cyber Resilience Act (CRA) and the Digital Operational Resilience Act (DORA) are making the adoption of best DevSecOps practices a legal requirement.

Hopefully, there will come a day soon when the quality of the code being generated by AI coding tools improves to the point where vulnerabilities are no longer a major issue. In the meantime, however, DevSecOps teams are in danger of being overwhelmed as the volume of code being generated continues to exponentially increase in the age of AI.

The only way DevSecOps teams are going to be able to at least minimize application security issues is by enforcing more policies. The challenge, of course, is that application developers will complain those policies are one of the reasons they are missing application delivery times. The only difference now is there is much broader recognition of the level of risk organizations encounter when there are either no policies or, worse yet, simply ignored.

March 23, 2026
DevOps: Don’t Let Detection Be a Bottleneck for Security

AI and automation can help ensure DevOps security doesn’t impact performance

The world revolves around software and internet-based applications—and speed is crucial. Users have very little patience for delays and will quickly jump to something else if performance lags. Organizations have embraced DevOps and containers in an effort to accelerate development and deployment of software and maintain a competitive edge over rivals. One of the biggest challenges, though, is how to identify vulnerabilities and detect security issues without significantly degrading performance.

There will always be some impact on performance. You are adding an extra layer of functionality—a layer of security intended to detect and resolve security issues. No matter how fast that detection is, it will still take more time than not having any detection at all. The goal is to implement detection with as little impact on performance as possible. You don’t want detection to be a bottleneck for your cybersecurity efforts, or a drag on performance in general.

Bridging the Gap Between Speed and Security

One of the defining characteristics of a cloud-based, containerized, DevOps environment is its dynamic and continuous nature. In an effort to streamline and accelerate business, organizations embrace continuous development, continuous integration and continuous deployment combined with continuous monitoring, continuous testing and continuous improvement—all of which require continuous security.

Real-time monitoring for suspicious or malicious activity is crucial. The internet doesn’t sleep, and attackers are constantly scanning and probing for vulnerabilities and weak links to exploit in your network and applications.

Security is important, but not at the expense of productivity. The challenge is how to bridge the gap between speed and security—and ensure you can detect attacks effectively without introducing undue friction. You need balance—security that provides necessary protection without defying the whole point of trying to streamline and accelerate business. In other words, security needs to become a guardrail rather than a roadblock for DevOps.

Improve Detection with Automation and AI

Real-time protection is necessary—but not all real-time security solutions are the same. How attacks are detected is as important—or more important—than just detecting them.

Why? Simple. Attack detection based on signatures or generic patterns such as a core rule set or regular expressions are not customized to recognize threats in the context of the application. For example, with a RASP (runtime application self-protection) solutions, even if the control points are good, the end result will be poor without the right context and detection techniques. This approach is also reactionary and leaves you exposed for some period of time. It is generally ineffective until the signature is developed, and the signature can’t be created until the threat is detected and identified.

Automation and artificial intelligence (AI) can accelerate the process and provide more effective protection with less friction. An AI-powered platform can learn from stateless traffic and deconstruct application logic to create application-specific rules—and update the rules dynamically without the need for human intervention. Using dynamic, application-specific rules rather than signatures and manual rules can result in efficient detection and an exceptionally low false-positive rate. An automated solution that leverages artificial intelligence also can protect without waiting for signature updates.

Modern Security for Modern Networks

The days of periodic scans are long gone. The network architectures and threat landscape today demand constant, real-time protection. Legacy detection techniques are cumbersome and can’t keep pace, but an AI-powered attack detection platform that is automated will be more effective for protecting a dynamic, cloud-based, containerized, DevOps environment.

— Tony Bradley

February 7, 2019
DevOps need to pay more attention to security

Ty Miller, founder of Threat Intelligence, suggests organisations adopting DevOps need to pay more attention to security.

Over the last five years or so, the prevailing approach to IT security has changed – largely triggered by the activities of hacktivist groups such as Anonymous and LulzSec – and it is becoming an increasingly integrated part of the application lifecycle, he said.

The less attention given to security in the earlier stages, the more likely it is that the application will have to be rearchitected and redeveloped before deployment, which can be 100 times more costly than building in security from the outset.

Since DevOps is often adopted to allow more frequent code releases, it is important that security is built into the process from start to finish, as there is no longer time for extensive security testing between completion and release.

Part of the problem is that developers tend not to be security experts, and because of their backgrounds security officers generally are not application security specialists. This can leave a security gap, he said.

Miller’s recommendations include:

Code libraries The reuse of known-good code instead of reinventing the wheel each time reduces the risk of building new vulnerabilities into software.

Platform security While IT teams would not dream of omitting intrusion prevention systems and other security components from an on-premises system, “these sorts of things are quite commonly being left out” from cloud deployments possibly because they are thought to be insufficiently scalable – a symptom of the tendency to sacrifice security for flexibility. And organisations sometimes assume that SaaS products are secure, even though they can “become large scale data breaches.” Recent research suggests around 90 percent of SaaS offerings are not sufficiently secure for enterprise use, he said.

Automated builds Automatically building systems based on pre-hardened templates helps reduce the risk of accidentally overlooking something and other human errors. If you can be confident that a new server will spin up in a secure configuration, development teams can concentrate on the code they are working on.

Automated security testing Frequent releases are at odds with traditional security testing, such as engaging specialist penetration testers before a major release. “That’s thrown a spanner into the works,” Miller said. When do you do the security testing? Can you pinpoint everything that has changed since the last test, and focus testing efforts accordingly? “Automated security testing needs to be built into the DevOps process,” he advised.

Fortify, AppScan and Burp Suite are among the more reputable tools, he said.

HP’s Fortify http://www8.hp.com/us/en/software-solutions/application-security/ , a code review tool, “is very expensive [at up to $120,000 per year] but also very good,” according to Miller, even though it generates false positives as other tools do.

IBM’s AppScan http://www-03.ibm.com/software/products/en/appscan/ helps with web and mobile app development, and costs around $30,000 per year, he said. While it has a good feature set and a convenient GUI, it does need a lot of setting up and maintenance when it comes to workflows.

PortSwigger’s Burp Suite http://portswigger.net/burp/ is a semi-automated scanner for web applications. At $300 per seat it is relatively cheap, and “virtually every penetration tester around the world uses it,” said Miller. It might not be as intelligent as the big-name commercial products, but “it is a very accurate scanner.”

But automated testing is not a panacea. Automated scans can find perhaps 20 percent of vulnerabilities, but that’s 20 percent less for humans to find. And the output of such tools tends to include many false positives, so some expertise is needed to interpret the results – an inexperienced user can waste a lot of time, Miller warned.

For example, access control flaws can be hard to detect automatically. Does changing a number in a URL produce a different page in the same report, or a report for a different customer? Is any particular report public or private? A penetration tester understands the application and can easily decide whether or not there is a security issue, but the best an automated tool can manage is to warn there may be a problem here.

An organisation that has a defined set of methodologies covering the entire process from development to production, implements security as a baseline feature in code and infrastructure builds, uses automated scanning and security testing, and integrates regular penetration tests and reviews “will be significantly ahead of other organisations,” Miller suggested.

About the Author:

Stephen Withers is one of Australia¹s most experienced IT journalists, covering everything from gadgets to enterprise systems. In previous lives he has been an academic, a systems programmer, an IT support manager, and an online services manager. Stephen holds an honours degree in Management Sciences, a PhD in Industrial and Business Studies, and is a senior member of the Australian Computer Society. You can see his Linkedin profile here: http://au.linkedin.com/pub/stephen-withers/0/222/687/

January 20, 2015