Skip to main content

Search...

Security, Regulation & Compliance

Security cannot be tested in at the end of a project, and regulatory demands keep growing, from the Cyber Resilience Act to standards such as IEC 62443. This hub connects security, regulation, and compliance with everyday quality work in development and testing.

The articles and podcast episodes cover secure by design, developing security requirements as a team, static analysis, fuzzing, penetration testing, and automated security checks. They also look at zero trust, using open source securely, legal questions in software contracts, and AI in regulated settings such as medical labs. They share one view: security is a job for the whole team.

Articles

Static Analysis: Finding Security Flaws Before Testing
Static Analysis: Finding Security Flaws Before Testing

Static Analysis: Finding Security Flaws Before Testing

Static analysis security testing finds many flaws in Java code before dynamic testing starts. In one study it took 2 person-months, dynamic testing 12.

Podcast Episodes

Dark Side of Testing: The Failures We Cause Ourselves
Dark Side of Testing: The Failures We Cause Ourselves

Dark Side of Testing: The Failures We Cause Ourselves

A test can leak data, expose code or bring down production. The dark side of testing begins with the setup, which needs a risk assessment of its own.

LLM Testing: A Second Model Acts as the Judge
LLM Testing: A Second Model Acts as the Judge

LLM Testing: A Second Model Acts as the Judge

LLM testing can be automated if you accept non-determinism: rubrics and acceptance ranges replace yes/no asserts, and a calibrated LLM judges outputs.

Open-Source Software: Four Requirements for Vendors
Open-Source Software: Four Requirements for Vendors

Open-Source Software: Four Requirements for Vendors

Open source compliance starts once you ship software. Vendors need license checks and an S-BOM, which the Cyber Resilience Act makes mandatory.

Security by Design: Why Custom Encryption Adds Risk
Security by Design: Why Custom Encryption Adds Risk

Security by Design: Why Custom Encryption Adds Risk

Security by design starts with threat modeling any team can run, layered defenses and secure defaults. Security bolted on in the last 10% stays thin.

AI Test Description: Test Cases Structured Like Code
AI Test Description: Test Cases Structured Like Code

AI Test Description: Test Cases Structured Like Code

An AI test description makes AI systems testable: five capabilities and quality criteria like correctness and bias turn standards into concrete tests.

Secure by Design: Security Starts at the Beginning
Secure by Design: Security Starts at the Beginning

Secure by Design: Security Starts at the Beginning

Secure by design means building security in from day one, not bolting it on later. What defense in depth, secure defaults and threat modeling look like.

Cybercrime: Organized Like a Startup
Cybercrime: Organized Like a Startup

Cybercrime: Organized Like a Startup

Cybercrime works like a start-up with a division of labor. Defenders should think like attackers, separate systems and not pay the ransom.