Tag: Checkmarx

60% of Code Is AI-Generated—Are We in Trouble?

Jonathan Rende, chief product officer at Checkmarx, tackle’s one of the most urgent questions in AppSec right now: what happens when AI starts writing the majority of your software?

With estimates that as much as 60% of code is being generated by AI in some environments—and that AI-authored code is already finding its way into production—the conversation quickly moves past novelty and into operational reality. The central theme is trust: should AI-generated code be treated differently than human-written code, and are organizations holding it to a higher standard simply because they’re less confident in how it was produced?

Rende unpacks how developer behavior is changing as copilots and agents make it possible to generate thousands of lines of code quickly, often faster than teams can realistically review it. That shift increases pressure on DevSecOps “outer loop” controls—static analysis, dynamic testing, supply chain security, and governance—to catch defects and vulnerabilities before they become incidents. The issue isn’t only volume; it’s also context. Even as models improve, secure outcomes still depend on how developers prompt, validate, and integrate AI output into real systems.

They also explore the evolving benchmark landscape for measuring model security performance and what those trends suggest: AI-generated code may be getting less vulnerable over time, but “less vulnerable” isn’t the same as “secure.” Rende argues that while common vulnerability patterns may decline, higher-order logic flaws and transitive issues will remain difficult—and may even become more prominent as applications and AI-driven supply chains grow more complex.

Whether code is written by humans or machines, production software still demands rigorous, continuous security testing—because in the AI era, the attack surface is expanding as fast as delivery velocity.

January 15, 2026

DevSec Relationship Status: It’s Complicated (But Fixable)

Remember that plastic Fisher-Price Shape Sorter from when you were a kid, where you had to fit different-shaped colorful blocks into their matching slots? And that oddly satisfying moment when the green triangle block slid out of your fingers and landed perfectly into place?

That tiny ASMR-inducing thrill of making all the parts of a system slide seamlessly into their place is alive within every DevOps architect or platform engineer. However, with modern-day DevOps infrastructure, that thrill often dissolves into frustration.

Fragmented security tools that weren’t built for DevOps pipelines, can often refuse to fit neatly into their workflows. But the challenge extends far beyond mismatched tools – it’s a clash of cultures. While developers race to meet relentless delivery deadlines in a cloud-native world, security teams watch their risk exposure expand with every deployment. Both teams remain entrenched in their separate realities, speaking different languages, chasing different goals.

How Serious is the DevSec Dissonance? Industry Data Speaks

In Checkmarx’ December 2024 AppSec Survey, performed by Visible Impact, a division of The Futurum Group, organizations were asked what’s standing in their way of optimal application security. The answers tell a familiar story:

38% of respondents say that a top problem they face is the eternal balancing act between speed and security.

29% report that making their security tools play nice with DevOps pipelines is a top challenge.

19% are wrestling with different processes for different security tools.

14% point to the elephant in the room: Poor collaboration between security and development teams

I’m not here to bring you down, of course. There’s a solution, but it’s not a single tool, integration, or a fancy new dashboard. It’s a guiding principle designed to ‘Make It All Work Together.’ – a call for a deep shift in the paradigm of how development and security interplay.

Toll of a Cultural Divide

Security and development evolved as distinct disciplines, each with their own tools, methodologies, and metrics.

Security teams emerged from risk management and compliance, while development teams were born in the age of agile and continuous delivery. Most security tools have been designed with security teams in mind, neglecting the needs of development, and vice versa.

In today’s enterprise environments, where DevSecOps processes have evolved into complex ecosystems, the challenge isn’t just integration – it’s scalability. Security tools that were either developed purely for AppSec professionals, or those designed for small dev team become bottlenecks when scaling up to manage thousands of pipelines, potentially with many different configurations, across multiple development teams.

Most application security tools weren’t designed with enterprise-scale DevOps pipelines in mind, and don’t align with current development and deployment practices. The impact of this misalignment manifests across the entire development ecosystem:

Developer productivity: The constant context-switching between various tools and the IDE creates delays, breaks flow state and contributes to burnout and fatigue.

Operational overhead: Managing multiple security tools comes with substantial costs in licensing, integration, maintenance, and operational complexity.

Knowledge fragmentation: Each tool introduces its own learning curve and best practices. multiplying the burden on all teams involved and complicates security training.

Risk Visibility Gaps: Without a single source of truth, teams lack visibility into application-level risk, leading to inaccurate risk assessment.

Understanding these challenges is the first step. Now let’s explore what it takes to bridge this divide.

How Do You “Make It All Work Together” in Practice?

Making It All Work Together requires four components: culture, integration, consolidation, and adaptation.

Culture

Developers need to embrace security as part of their process, another engineering challenge to solve. Equally important, security teams need to embrace DevOps culture, moving away from traditional gated approaches toward automated, pipeline-native security controls that match development velocity.

Integration

Security controls need to maintain pipeline velocity, work from within the IDE and integrate with developer workflows. Implementations must remain consistent across all pipelines, repositories, and teams, bridging the gap between security and development through shared processes.

Consolidation

The more AppSec and dev teams are involved, each making their own decisions on which tools they’re going to use and how to use them in their process, the problem of tool sprawl multiplies exponentially. What’s an arguably manageable issue with a small team becomes a chaotic web of incompatibility. That’s why consolidation is imperative.

Consolidating your AppSec tools into one unified platform that covers all stages of the SDLC provides a seamless, developer-centric experience across all teams involved. For consolidation to be effective, the platform must cover everything from code, through supply chain, to cloud and deployment.

Consolidation not only helps streamline current work processes across different tools and teams, but also, equally importantly, facilitates further scalability.

Adaptation

‘Making it All Work Together’ is a process of progressive change, trial –and-error, and continuous improvement. Monitor how your teams interact with security tools, track key metrics, and fine-tune your approach accordingly.

Who Benefits from “Making It All Work Together”? Everyone

DevOps and Platform Engineering leaders have much to gain here being the ones dealing with the challenge, and the impact ripples across all teams and stakeholders. Let’s break down the benefits:

DevOps/Platform Engineering leaders

Developers

AppSec Managers

Support more dev teams on their security requirements with fewer tools

A unified view across your teams and pipelines for easy reporting on security and compliance requirements

Streamlined onboarding and reduced overhead

Cost reduction through consolidated licensing

Centralized policy management to catch issues early in the pipeline

Single point of contact for support

No more context-switching between security tools

Clear, prioritized security guidance in existing workflows

Faster vulnerability remediation with contextual guidance

Easier adoption of secure development practices

Correlated findings reducing overall ticket load

Automations to optimize security feedback loops and reduce cycle time

Complete visibility across the application portfolio

Better adoption of tools by developers

Faster remediation times with centralized security data

Reduced friction in DevSecOps workflows

Pipeline-native security driving cultural adoption

Ultimate reduction in application security risk

When Every Piece Clicks into Place

Creating a harmonic environment consolidating security into the SDLC is never about a single tool or process- tweaking. It takes a rethinking at the molecular level about how development and security interact, and while tech itself is not enough, it’s the foundation for change.

Integration and consolidation – two of the four principles of the “Make It All Work Together” mindset – are very much dependent on a unified AppSec platform that can integrate security tools seamlessly into the SDLC, help manage pipeline load and streamline dev and sec collaboration.

Ready to forge a new DevSecOps experience?

Explore how Checkmarx can help:
[checkmarx.com/solutions/devsecops]

February 25, 2025

Checkmarx Report Details Havoc Caused by ‘Everything’ Package on NPM Registry

Checkmarx this week released a report detailing a package distributed via the NPM registry that cripples any machine that is used to download it.

Dubbed the “Everything” package, a user known as PatrickJS, also known as gdi2290, uploaded a package that has more than 3,000 sub-packages. Each sub-package is designed to split dependencies into chunks and to depend on all publicly available NPM registry packages, resulting in transitive dependencies that disrupt pipelines and exhaust storage space.

Following significant effort, The Everything package has since been removed from the registry, but the perpetrators did create a domain where they showcase their handiwork. Whether the Everything package was created as a joke to be played on developers or has some other malicious vandalistic intent is unclear.

Jossef Harush Kadouri, head of software supply chain security for Checkmarx, said these types of incidents are likely to happen from time to time because there is no process for reviewing packages prior to them being loaded into a registry. In fact, a similar incident previously occurred when a “no-one-left-behind” package by Zalastax that was dependent on every publicly available npm package was uploaded in the registry.

It’s only when an issue is identified that the maintainers of the NPM registry will remove a package. Those maintainers simply lack the resources and tools that would be required to scan every package, noted Harush Kadouri.

Heading into 2024, it will be incidents like these, along with vulnerabilities found in NPM packages, that will serve as an impetus for reviewing the workflows that make up an organization’s software supply chain. For well over a decade, developers have been downloading software components from various repositories with little to no regard for vulnerabilities. As more of those vulnerabilities are exploited, organizations that rely on that software are now requiring providers of applications to provide visibility into the provenance of the components used to construct it. The overall goal is to make it simpler to remediate applications, especially when a zero-day vulnerability is discovered.

In the meantime, organizations would be well-advised to curate a repository of software components that have been vetted. Developers can still readily access those components to build applications, but there should be fewer downstream application security issues if the components residing in that registry have been scanned. If developers are allowed to directly download packages and components from a public registry, it’s only a matter of time before an application security issue is going to arise.

Hopefully, as organizations adopt DevSecOps best practices, the number of application security issues encountered will steadily decline. Each organization will need to determine how far left to shift responsibility for application security toward developers, but one way or another, software supply chains need to be better protected.

Of course, the issue will ultimately be forced by regulations that are becoming increasingly more stringent. Once the first fines are levied, it won’t be long before just about every organization that builds and deploys software will quickly move to limit their liability as much as possible. The challenge and the opportunity now is to proactively secure software supply chains today before any remedy that might be imposed on an organization disrupts application development workflows tomorrow.

January 5, 2024
Checkmarx Surfaces Threat to GitHub Repositories

Checkmarx, a provider of application security testing tools, today reported that malicious actors have been able to compromise the free automated dependency management tool for software projects, known as Dependabot, that GitHub provides.

It’s not clear how prevalent the compromise is, but the attack involves the tokens that GitHub provides to allow access to Dependabot. Once cybercriminals gain access to a repository, they then add additional emails to the account that, once authorized, are used to inject malicious code into a repository that exfiltrates defined secrets to an external server. Cybercriminals can then modify any existing JavaScript files using a password-stealer to steal the credentials of any end user submitting their password in a web form.

Guy Nachshon, a security researcher for Checkmarx, said Checkmarx was only able to discover the threat because one of the cyberattackers made a mistake. DevOps teams are advised to confirm the identity of each user that has access to both public and private GitHub repositories to ensure their software supply chain has not been compromised, he added.

In general, attacks against software supply chains are becoming more sophisticated, noted Nachshon. Beyond launching phishing attacks to steal the credentials of individual members of an application development team, it appears cybercriminals are employing tactics and techniques that enable them to steal the credentials of an entire team contributing to a repository.

These attacks, of course, have become a matter of national security. Governments around the world are crafting legislation that will hold organizations more accountable for the security of the applications they build and deploy. It may be a while before those proposals become law, but it’s clear the pressure on organizations to secure their software supply chains is building. More organizations than ever are, as a result, embracing DevSecOps best practices to better protect their software supply chains.

The challenge is that many of the components used within those supply chains are from open source projects that organizations don’t have the ability to patch should a vulnerability be discovered. More troubling still, even when a patch is available, many organizations are reluctant to upgrade for fear of breaking an application. In effect, they are betting cybercriminals are not going to discover a potential exploit that exists in their application portfolio or that the damage inflicted will be less than what might otherwise be experienced should an application break following the update of a critical component.

Playing the equivalent of Russian Roulette with application security is, to put it mildly, inadvisable. DevSecOps teams need to not only address vulnerabilities in applications as they are being built but also address the massive amount of technical debt relating to known vulnerabilities that have been allowed to accrue for more years than most anyone cares to admit.

Unfortunately, cybercriminals are now clearly aware of the soft underbelly that exists within application environments, so the race to address an issue that has been allowed to fester is now on. And the odds, alas, are already stacked in favor of the malicious actors that are ready and willing to wreak havoc.

September 27, 2023
Checkmarx Brings Generative AI to SAST and IaC Security Tools

Under an early access program, Checkmarx today made available query builder and guided automation tools that take advantage of OpenAI’s generative artificial intelligence (AI) technologies to make it simpler for developers to resolve application security issues.

AI Guided Remediation surfaces actionable remediation recommendations for vulnerability issues such as misconfigurations directly from within integrated development environments (IDEs).

Meanwhile, AI Query Builder makes it possible to use natural language text to create a query for both the Checkmarx static application security testing (SAST) and the infrastructure-as-code (IaC) security tool that creates rules for scanning code. Those rules can be easily fine-tuned or modified and queries for other use cases can easily be added.

In addition to reducing the amount of time it takes to create a query by 65%, that approach also dramatically reduces the number of false positive alerts that arise based on rules created by a security administrator.

Checkmarx CEO Sandeep Johri said these additions to the Checkmarx One Application Security Platform are aimed at improving the application security experience for developers. Most developers don’t want to be inundated by alerts that lack any real context, nor do they want to be bothered with remediation details.

It’s not likely developers will be interested in how AI could help them write more secure code from the start, but the faster a reliable fix is surfaced, the sooner developers can return to writing code, noted Johri.

In the longer term, Checkmarx will add support for multiple large language models (LLMs) beyond those provided by OpenAI to provide other AI capabilities that are based on more domain security knowledge, said Johri.

However, despite these advances, vulnerability remediation will not become fully automated using AI any time soon, he added. Instead, it will become much simpler to identify code that has either inadvertently or deliberately introduced a vulnerability, said Johri.

In fact, generative AI tools such as GitHub Copilot can themselves introduce vulnerabilities into code. As a general-purpose AI platform, the recommendations surfaced are based on a mix of instances of clean and flawed code, Johri noted. There will also be instances where cybercriminals attempt to subvert an LLM that creates code by injecting snippets loaded with malware into the samples used to train a generative AI model.

On the plus side, however, generative AI tools should narrow the divide that currently exists between application developers and cybersecurity teams as more issues are discovered and remediated before applications are deployed in a production environment. The challenge has aways been surfacing application security issues at the time developers are writing code rather than sending them a list of vulnerabilities to address weeks (sometimes even months) after a developer has moved on to another project.

Naturally, there is a lot of trepidation when it comes to all things generative AI; one area of certainty is that the benefits far outweigh the risks—especially when it comes to developing secure-by-default applications.

May 31, 2023
Checkmarx Report Highlights Need for AppSec Collaboration

A research report published by Checkmarx finds the same basic malicious software developed using multiple programming languages as cyberattackers industrialize their malware development processes.

Checkmarx, a provider of code scanning tools, shared examples of malicious packages written in multiple programming languages. These example packages share the same indicators of compromise that have gone undetected for years. A “junkeldat” PyPI package for Python applications, for example, that has been compromised also shows up in a Ruby version of the package.

Tzachi Zornstain, head of supply chain security for Checkmarx, said much like any other development team that uses multiple programming languages, it appears cybercriminals are also sharing techniques. These examples highlight the need for development teams to share security intelligence even if they build applications using different programming languages, he added. There is a tendency for development teams using one programming language to ignore application security issues that appear to only impact applications written in another programming language, noted Zornstain.

The fact that the packages remained undetected for such a long period of time is due—at least in part—to the lack of information sharing in the ecosystem, said Zornstain.

Cyberattackers are, of course, trying to take advantage of the implicit trust many development teams have in open source projects. However, now that more cybercriminals are making a concerted effort to compromise downstream software components, it’s imperative that every component be vetted, said Zornstain. In fact, organizations should not use any code provided by strangers, he advises.

The core issue is that many open source projects are maintained by a small number of programmers contributing their time and effort to building components that others are free to use. Many of them argue that the onus for making sure software is secure is on the organizations that decide to deploy that software. Nor is it their responsibility to keep track of cybercrimimals distributing malicious versions of their software.

Unfortunately, many IT vendors and large enterprise IT organizations that rely on that code are, unfortunately, not contributing anything meaningful back to the project, either in terms of financing or helping open source maintainers find and remediate vulnerabilities. Many of those same organizations, however, are assessing whether the open source software they employ is, from a security perspective, actually sustainable in the absence of those contributions. As a result, it may be only a matter of time before these long-simmering open source software security concerns boil over into a larger crisis.

One way or another, DevSecOps best practices will need to be applied to application development at a deeper level. Organizations can’t assume that the software components they are relying on have been scanned for vulnerabilities by someone else. It’s simply too easy for a development team to make a mistake. The need for higher levels of security may lengthen the development process, but the alternative—malware infestations wreaking havoc—is far less desirable.

May 9, 2022
Checkmarx Finds Malicious Open Source PyPi Repository

Checkmarx, a provider of a platform for testing application security, this week disclosed it has discovered a malicious instance of a PyPi repository for Python code that has been downloaded more than 70,000 times.

Tzachi Zorenshtain, head of supply chain security, said this discovery represents another instance where cybercriminals have made available a malicious copy of a popular open source software package that contains malware that is destined to find its way into downstream applications. Cybercriminals, via a tactic known as starjacking, create a web page that includes bogus statistics, such as GitHub stars, to make it appear a software package that a developer might download is from a legitimate open source project, he noted.

Cybercriminals are combining starjacking with typosquatting to set up web pages to mimic a legitimate open source project, noted Zorenshtain.

Starjacking represents yet another effort to compromise the integrity of software supply chains that rely on a wide range of open source software components to build applications. The only way to thwart starjacking is for either developers or DevOps teams to validate components before incorporating them within applications, noted Zorenshtain. Otherwise, it’s possible malware will only be discovered after it has already found its way into downstream applications deployed in a production environment.

The challenge, of course, is remembering to take the time to validate the source of any software component. Developers that are typically trying to build applications as fast as possible don’t always stop to make sure that all the components they are employing are from a legitimate source.

It’s not clear how pervasive fake sites through which developers are encouraged to download malicious software have come to be. However, as cybercriminals expand their efforts to compromise software supply chains, it’s clear their tactics are evolving in ways that exploit the trust developers have in open source software. It’s not likely these attacks will disrupt the open source ecosystem, but they do add additional urgency to make open source software more secure.

The Open Source Security Foundation (OpenSSF), an arm of the Linux Foundation, has raised more than $10 million to build tools and define best practices for securing open source software projects. Google has pledged to ultimately spend $10 billion to improve open source security. The Biden administration has also made improving the security of open source software that is widely employed both inside and out of government agencies a priority by expanding compliance mandates. The White House is also clearly trying to pressure IT vendors and larger enterprises to contribute more to the effort to secure open source software.

The trouble is many open source projects are maintained by a small number of programmers that contribute their time and effort to building components that others are free to use. Many of them argue the onus for making sure that software is secure is on the organizations that decide to deploy that software. Nor is their responsibility to track down cybercrimimals that employ Typosquatting techniques to distribute malicious versions of their software.

Many of the IT vendors and large enterprise IT organizations that rely on that code are, unfortunately, not contributing anything meaningful back to the project, either in terms of financing or just helping open source maintainers find and remediate vulnerabilities. Many of those same organizations, however, are now also assessing whether the open source software they employ is, from a security perspective, actually sustainable in the absence of those contributions. As a result, it may now be only a matter of time before a long-simmering open source software security issue erupts into a major crisis of confidence.

April 20, 2022
Checkmarx Appoints Roman Tuma as Chief Revenue Officer

Veteran security leader to oversee Checkmarx’s go-to-market strategy and drive demand for developer-centric AST solutions

Ramat Gan, Israel, June 10, 2021 — Checkmarx, the global leader in developer-centric application security testing solutions, today announced that it has named Roman Tuma as Chief Revenue Officer (CRO). Previously the Vice President of Sales for Checkmarx’s EMEA, LATAM, and APAC business, he will now be responsible for driving the company’s go-to-market strategy including overseeing global sales, channel operations, and strategic alliances.

During his tenure at Checkmarx, Tuma has been instrumental in growing the company’s revenue and customer base in Europe, Latin America, and Asia-Pacific, as well as streamlining global sales processes and forging new partnerships and alliances. Moving forward, he will continue this momentum and position Checkmarx for its next phase of growth by introducing new routes to market, expanding its network of customers and partners, and redefining the way code scanning and testing is consumed.

“Roman brings an unparalleled level of strategy, leadership, and energy to his new position as CRO. As an industry veteran, his proven track record of success in scaling companies is a testament to his deep cybersecurity and cloud expertise, outstanding sales strategy and execution, and innovative mindset,” said Emmanuel Benzaquen, CEO, Checkmarx. “All organizations around the globe are grappling with today’s dynamic and complex application security landscape, and Roman will be essential in helping to meet and exceed their needs while also evolving Checkmarx’s business.”

Tarim Wasim, Partner at Hellman & Friedman, which acquired Checkmarx last year, added, “Roman has demonstrated clear and sustained success, making him the ideal fit to join the Checkmarx management team and assume the role of CRO. During his time leading sales in EMEA, LATAM, and APAC, he has been a cornerstone of the team. We’re excited to welcome Roman to his new global position as we build on what has already been a very strong year for Checkmarx.”

Tuma possesses more than 27 years of experience – 17 of which have been spent in the cybersecurity industry – building and operating high-growth, customer-oriented teams. Prior to Checkmarx, he spent over 10 years at IBM in multiple executive positions, including Vice President of IBM Hybrid Cloud where he oversaw sales, revenue growth and profitability, technical support, and cloud solution implementation strategy. Prior to this, Tuma held various leadership and sales roles at Oracle, Sun Microsystems, and ActivCard.

“Checkmarx’s deeply-rooted AppSec and DevOps history, unique understanding of developer needs, and innovative approach to application security testing is a winning recipe for success,” said Tuma. “I’m excited to build on Checkmarx’s position as the market leader in AST, while driving value for every organization that’s concerned with developing secure applications and software.”

About Checkmarx

Checkmarx is the global leader in software security solutions for modern enterprise software development. Checkmarx delivers the industry’s most comprehensive Software Security Platform that unifies with DevOps and provides static and interactive application security testing, software composition analysis, and developer AppSec awareness and training programs to reduce and remediate risk from software vulnerabilities. Checkmarx is trusted by more than 40 of the Fortune 100 companies and half of the Fortune 50, including leading organizations such as SAP, Samsung, and Salesforce.com. Learn more at www.checkmarx.com.

June 10, 2021
Checkmarx Launches Infrastructure as Code Scanning Solution to Secure Cloud-Native Applications
Open source IaC scanning engine is industry’s most comprehensive solution for enabling developers to detect and fix configuration issues
February 25, 2021 09:05 AM Eastern Standard Time
RAMAT GAN, Israel–(BUSINESS WIRE)–Checkmarx, the global leader in software security solutions for DevOps, today announced the launch of KICS (Keeping Infrastructure as Code Secure), an open source static analysis solution that enables developers to write more secure infrastructure as code (IaC). With KICS, Checkmarx expands its AST product line, providing a single platform for securing proprietary code, open source components, and critical infrastructure for both traditional and cloud-native applications.

The adoption of IaC has risen considerably in recent years as organizations transition to the cloud and seek ways to make the provisioning of infrastructure faster and more scalable. However, with all the benefits of IaC comes a multitude of security, compliance, and configuration risks that developers are struggling to address. This is realized when considering that error-related issues (e.g. misconfigurations and misdeliveries) are now the second biggest cause of data breaches.

KICS automatically detects vulnerabilities, hard-coded keys and passwords, compliance issues, and misconfigurations from the very start of the IaC build cycle, allowing developers to easily remediate these flaws before reaching production. As the most comprehensive IaC scanning engine available, KICS supports the top IaC technologies including Terraform, Kubernetes, Docker, AWS CloudFormation, and Ansible. Additionally, KICS offers more than 1,200 fully customizable and adjustable queries, which cover more than 12 categories ranging from encryption and key management to network ports security.

“As development processes evolve and organizations accelerate their cloud adoption, developers are taking on more security responsibility while also delivering software faster than ever before. This is an impossible balance to strike by solely relying on manual, time-consuming code reviews,” said Maty Siman, CTO and Founder, Checkmarx. “KICS was built with this in mind, enabling development teams to automatically identify IaC issues when fixing is quickest, cheapest, and easiest. As the newest addition to the Checkmarx product portfolio, developers now have a single destination for securing all components that make up today’s complex applications.”

Additional key features and benefits of KICS include:

Built-in extensibility: KICS provides the largest ‘library’ of queries of any IaC scanning solution, all of which are fully customizable and adjustable. Additionally, KICS’ robust, yet simple, architecture allows for the quick addition of support for new IaC tools.

Community-sourced: As an open source project, both the scanning engine and queries for KICS are clear and open to a community of thousands of security and DevOps experts and software developers. Coupled with Checkmarx’s dedicated team that is constantly adding new features and vetting contributions, KICS is able to scale at a rapid pace.

Seamless CI/CD integration: KICS can easily be integrated with any CI/CD pipeline, including GitHub Actions and GitLab CI, applying vulnerability and misconfiguration checks to IaC while keeping developers within their preferred tools.

Siman continued, “Checkmarx is a strong advocate of open source projects, and creating KICS in this manner gives the community the opportunity to steer its direction and foster innovation across the industry. We’re excited to watch this passionate community embrace and contribute to KICS as it becomes an essential addition to every developer’s cloud-native security toolkit.”

“I’m proud to welcome Checkmarx to the open source ecosystem with the release of KICS, as the company brings its vast AST experience to the community,” said Lior Kaplan, open source advisor and evangelist. “KICS is already seeing significant interest from the DevOps and security experts who take part in open source, and this will continue to grow as the project scales and expands to more infrastructure as code platforms.”

KICS is available for free today. To learn more, visit kics.io.

About Checkmarx
Checkmarx is the global leader in software security solutions for modern enterprise software development. Checkmarx delivers the industry’s most comprehensive Software Security Platform that unifies with DevOps and provides static and interactive application security testing, software composition analysis, and developer AppSec awareness and training programs to reduce and remediate risk from software vulnerabilities. Checkmarx is trusted by more than 40 of the Fortune 100 companies and half of the Fortune 50, including leading organizations such as SAP, Samsung, and Salesforce.com. Learn more at www.checkmarx.com.
February 25, 2021
Case Study – Travis Perkins plc by Checkmarx

With over 20 leading brands providing various online services for tens of thousands of consumers, Travis Perkins had the need for a strong AppSec solution in its arsenal to protect its applications. As the company shifted to an agile workflow, their development process became more fast-paced and it became evident that the company needed a strong AppSec solution that could keep up with the speed. This case study was done by Travis Perkins using Checkmarx to create a strong AppSec solution:

[su_button url=”https://devopsy.kinsta.cloud/wp-content/uploads/2020/07/CaseStudy_TravisPerkins_Checkmarx-solution.pdf” target=”blank” background=”#ef2d3f”]Download Now[/su_button]

August 1, 2020