Persistent cybersecurity threats from opportunistic actors demand continuous vigilance, with challenges in testing abstract security requirements and emphasizing early error detection over costly post-release fixes. Integrating measurable security goals, adaptive frameworks like OWASP ASVS, and team-driven practices is critical, alongside proactive strategies to address evolving risks in fields like AI and regulatory gaps.

Richard Seidl Software Testing

This is the other podcast on Software Testing by Richard Seidl, the episodes are in spoken German but the show notes and site are written in English. Our summaries are generated from AI transcript translations.

• https://www.richard-seidl.com/en/blog/tag/podcast-software-testing
• https://www.richard-seidl.com/en/

Episode Details

• Show Notes: https://www.richard-seidl.com/de/podcast/security-requirements-testbar-machen
• Published: 2026-05-26T04:00:00Z
• Duration: 00:23:42
• Author: Richard Seidl - Experte fur Software-Entwicklung und Testautomatisierung

Overview

The summary outlines persistent cybersecurity threats, including frequent attack attempts primarily from opportunistic IT companies conducting mass scans for profit, emphasizing the need for continuous vigilance. It highlights challenges in testing non-functional security requirements, which are often abstract and prone to over-testing, leading to delays without meaningful benefits. Early detection of errors is prioritized due to the significantly higher cost of post-release fixes. Security requirements are critiqued for lacking concrete, testable expressions compared to other quality attributes, though the CIA triad (Confidentiality, Integrity, Availability) can be operationalized through specific questions during requirement gathering. Additional security goals like authenticity and non-repudiation require balancing trade-offs, and clarity on data types (e.g., public vs. confidential) is essential for defining requirements.

The text advocates for integrating security as measurable goals similar to quality scenarios, using threat modeling during design phases rather than post-release testing. Security frameworks like OWASPs ASVS are noted as practical tools requiring customization to specific systems, with compliance levels (13) tailored to risk profiles. Security processes must remain iterative, especially in fast-evolving fields like AI, where reassessments are triggered by new components, incidents, or emerging threats like AI-specific vulnerabilities (e.g., prompt injection). Emphasis is placed on identifying protectable assets, fostering team-based security practices (e.g., developers taking primary responsibility), and using gamified threat modeling exercises to engage non-experts. Regulatory guidelines, such as the Cyber Resilience Act, are discussed as critical for encouraging early security prioritization, though adoption remains slow. Finally, the reality of cyber threats is underscored as pervasive, with attacks often going unnoticed until after breaches occur, requiring proactive, continuous mitigation strategies.

What If

• What if you integrated ASVS compliance into your project’s architecture early on?
  Concrete move: Select an ASVS compliance level (1, 2, or 3) based on your system’s data sensitivity and security requirements (e.g., Level 3 for systems handling confidential data).
  Why now: The Cyber Resilience Act, effective by autumn, mandates early security prioritization, and non-compliance with relevant standards (like cryptography for confidential data) will become legally risky.
  Expected upside: Proactively align with regulatory expectations, reduce post-release vulnerability risks, and ensure your system meets industry benchmarks for security rigor.

• What if you used threat modeling card games to identify attack scenarios during development?
  Concrete move: Host a 30-minute remote session with your team (or solo) using an online version of Elevation of Privilege or Comma Copia to simulate attack scenarios relevant to your system.
  Why now: Persistent attacks from opportunistic IT companies and emerging AI threats (e.g., prompt injection) require frequent risk reassessment, and games provide a low-effort, engaging way to surface vulnerabilities.
  Expected upside: Surface overlooked attack vectors early, improve team security awareness, and prioritize mitigation strategies before release.

• What if you formalized security requirements using concrete CIA triad questions during requirement gathering?
  Concrete move: For each feature, ask stakeholders:

  • “Whats the impact if this data is exposed?” (Confidentiality)
  • “What if unauthorized changes occur here?” (Integrity)
  • “What if this system goes offline?” (Availability)
    Why now: Security requirements are often abstract, and the cost of post-release fixes is exorbitanta 2027 expansion of the Cyber Resilience Act will penalize lax security practices.
    Expected upside: Create testable, specific security requirements that reduce ambiguity, align stakeholder expectations, and cut down on rework during later testing phases.

Takeaway

• Integrate security early in the design and architecture phases to avoid costly late-stage fixes, using threat modeling and security scenarios to identify risks before implementation.
• Adopt the OWASP ASVS framework with tailored compliance levels (Level 13) based on your systems specific data and security needs, ensuring practical alignment with your softwares requirements.
• Use gamified threat modeling exercises like Elevation of Privilege or Comma Copia to collaboratively identify vulnerabilities during informal team meetings or solo brainstorming sessions.
• Reassess security requirements whenever new components, data types, or attack vectors (e.g., AI-specific threats like prompt injection) are introduced to maintain alignment with evolving risks.
• Act as your own security spokesperson during development, advocating for security discussions in meetings, and proactively asking stakeholders concrete questions about confidentiality, integrity, and availability impacts.