Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

A couple days ago, I told you how a spammer got a certificate for dev-docs.trackjs.com, and that we only found out because Google emailed us. Google knew because the spammer claimed the hostname in Search Console. An attacker running a phishing page wouldn’t have done that, but they would still need a certificate. Every publicly trusted certificate gets written to a public log, and we track that log in our database. We just weren’t watching it. Now we are, and you can too.

On August 27, Google sent us an email. We did not. We barely recognized the hostname. None of us had thought about dev-docs.trackjs.com in about ten years.

Infrastructure-as-code (IaC) security scanning can catch common misconfigurations before deployment, but every organization also has internal requirements that a default rule catalog cannot cover. For example, teams may need to enforce required tags, approved instance types, or naming conventions. With custom rules for Datadog IaC Security, security and platform teams can define these requirements as Rego policies and run them alongside Datadog’s default rules during IaC scans.

Most conversations about PCI DSS 4.0 start with the requirements, but I’d rather start with a habit. As a GRC & Cybersecurity Consultant advising organizations preparing for PCI DSS 4.0 assessments, I’ve developed a habit of observing how findings move from identification to ownership, remediation, and documented closure. That’s often where accountability gaps and unresolved findings surface first.