In part one of our series on PCI DSS 4.0, we covered the updates in the latest version 4.0.1 and how to operationalize those changes. In this blog we are going to dig deeper into Requirement 11.6, how to interpret the nuance and automate the current guidance. Guidance that will become a mandate in March, 2025. Let’s start with what Requirement 11.6 is and why it’s so important.

As the Payment Card Industry Data Security Standard (PCI DSS) compliance standards continue to evolve, our team has been fielding a number of questions about the changes to 4.0, how to interpret them and ultimately how to get or remain compliant. We decided to create a blog series covering some of these recent changes with practical, actionable tips for getting started. Many organizations subject to PCI-DSS may not be aware that the latest version, PCI 4.0.1 has been released.

Protecting your e-commerce platform from unauthorized changes and skimming attacks is paramount for maintaining trust and ensuring compliance with PCI DSS 4.0, specifically requirement 11.6. This guide will walk you through utilizing Feroot platform to set up effective monitoring and response mechanisms for your payment pages.

This user guide will walk you through how to use Feroot’s suite of tools to meet PCI-DSS requirement 6.4.3 on your e-commerce webpages that handle card payments.

The Payment Card Industry Data Security Standard (PCI DSS) 4.0, issued a comprehensive set of requirements, to safeguard online payment systems against breaches and theft of cardholder data. Requirement 6.4.3 is one of the critical components for businesses that take online payment and focuses on the management and integrity of scripts on webpages that take payment card (i.e.m credit card) payments.

Programs and apps are a manifestation of ideas in a digital format. If you can dream it in other languages, WebAssembly can deliver it to the browser. From games ported from Unity to PDF editing on the web and leveraging interactive data from Jupyter and Rust, WebAssembly’s use cases are countless. WebAssembly (Wasm) is gaining traction to deliver high-performance client-side code that often cannot be created or executed by JavaScript, at least not in a performant way.

JavaScript is the most commonly-used programing language, according to the most recent StackOverflow developer survey. While JavaScript offers great flexibility and ease of use, it also introduces security risks that can be exploited by attackers. In this blog, we will explore vulnerabilities in JavaScript, best practices to secure your code, and tools to prevent attacks.

Zeek® is the world’s most widely used network security monitoring platform and is the foundation for Corelight network evidence. In this blog I share how to write a Zeek package in TypeScript with a new capability called ZeekJS that was released as part of Zeek 6.0.

According to Snyk's 2022 State of Open Source Security report, the average JavaScript project has 49 vulnerabilities, including common ones like unsafe dependencies, cross-site scripting (XSS), weak input validation, and cross-site request forgery (CSRF). And given JavaScript's widespread use, robust security measures are increasingly important to safeguard your applications from cyberattacks.