Get in Touch

Course Outline

A01:2025 – Broken Access Control

Access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification or destruction of all data, or performing a business function outside the user's limits.

Practical Aspects

  • Practical examples of broken access controls

  • Secure access controls and best practices

A02:2025 – Security Misconfiguration

Security misconfiguration is when a system, application, or cloud service is set up incorrectly from a security perspective, creating vulnerabilities.

Practical Aspects

  • Real-world examples of misconfigurations

  • Steps to prevent misconfiguration, including configuration management and automation tools

A03:2025 – Software Supply Chain Failures

Software supply chain failures are breakdowns or other compromises in the process of building, distributing, or updating software. They are often caused by vulnerabilities or malicious changes in third-party code, tools, or other dependencies that the system relies on.

A04:2025 – Cryptographic Failures

Generally speaking, all data in transit should be encrypted at the transport layer (OSI layer 4). Previous hurdles such as CPU performance and private key/certificate management are now handled by CPUs having instructions designed to accelerate encryption (e.g. AES support) and private key and certificate management being simplified by services like LetsEncrypt.org with major cloud vendors providing even more tightly integrated certificate management services for their specific platforms.

Beyond securing the transport layer, it is important to determine what data needs encryption at rest as well as what data needs extra encryption in transit (at the application layer, OSI layer 7).

For example, passwords, credit card numbers, health records, personal information, and business secrets require extra protection, especially if that data falls under privacy laws, e.g., EU's General Data Protection Regulation (GDPR), or regulations such as PCI Data Security Standard (PCI DSS).

Practical Aspects

  • Detailed analysis of cryptographic failures such as weak encryption algorithms or improper key management

  • Importance of strong cryptographic mechanisms, secure protocols (SSL/TLS), and examples of modern cryptography in web security

A05:2025 – Injection

An injection vulnerability is a system flaw that allows an attacker to insert malicious code or commands (such as SQL or shell code) into a program's input fields, tricking the system into executing the code or commands as if it were part of the system. This can lead to truly dire consequences.

Practical Aspects

  • Detailed breakdown of SQL, NoSQL, OS, and LDAP injection

  • Mitigation techniques using prepared statements, parameterized queries, and escaping inputs

A06:2025 – Insecure Design

Insecure design is a broad category representing different weaknesses, expressed as “missing or ineffective control design.”

Insecure design is not the source for all other Top Ten risk categories. Note that there is a difference between insecure design and insecure implementation. We differentiate between design flaws and implementation defects for a reason, they have different root causes, take place at different times in the development process, and have different remediations.

A secure design can still have implementation defects leading to vulnerabilities that may be exploited. An insecure design cannot be fixed by a perfect implementation as needed security controls were never created to defend against specific attacks.

One of the factors that contributes to insecure design is the lack of business risk profiling inherent in the software or system being developed, and thus the failure to determine what level of security design is required.

Practical Aspects

  • We'll explore design flaws that can lead to vulnerabilities, like improper input validation

  • We'll study strategies for secure architecture and secure design principles

A07:2025 – Authentication Failures

When an attacker is able to trick a system into recognizing an invalid or incorrect user as legitimate, this vulnerability is present.

Practical Aspects

  • Common authentication issues

  • Secure authentication strategies, like multi-factor authentication and proper session handling

A08:2025 – Software or Data Integrity Failures

Software and data integrity failures relate to code and infrastructure that does not protect against invalid or untrusted code or data being treated as trusted and valid.

An example of this is where an application relies upon plugins, libraries, or modules from untrusted sources, repositories, and content delivery networks (CDNs).

An insecure CI/CD pipeline without consuming and providing software integrity checks can introduce the potential for unauthorized access, insecure or malicious code, or system compromise.

Another example for this is a CI/CD that pulls code or artifacts from untrusted places and/or doesn't verify them before use (by checking the signature or similar mechanism).

Practical Aspects

  • Focus on issues like untrusted software updates and data tampering

  • Safe update mechanisms and data integrity checks

A09:2025 – Security Logging and Alerting Failures

Without logging and monitoring, attacks and breaches cannot be detected, and without alerting it is very difficult to respond quickly and effectively during a security incident.

Insufficient logging, continuous monitoring, detection, and alerting to initiate active responses occurs any time.

Practical Aspects

  • Importance of logging security-relevant information and monitoring for suspicious activities

  • Tools and practices for proper logging and real-time monitoring to detect breaches early

A10:2025 – Mishandling of Exceptional Conditions

Mishandling exceptional conditions in software happens when programs fail to prevent, detect, and respond to unusual and unpredictable situations, which leads to crashes, unexpected behavior, and sometimes vulnerabilities.

This can involve one or more of the following 3 failings:

  • The application doesn't prevent an unusual situation from happening

  • It doesn't identify the situation as it is happening

  • It responds poorly or not at all to the situation afterwards

SAST – Static Application Security Testing

  1. What static analysis is and when to run it in the SDLC (shift left)

  2. Types of vulnerabilities detectable through SAST, vulnerable code vs secure code

  3. Overview of SAST tools (e.g. Semgrep, SonarQube, Checkmarx, depending on client stack)

  4. Practical exercise: run a SAST scan on a repository with deliberately introduced vulnerabilities, interpret results, triage false positives vs real vulnerabilities

DAST – Dynamic Application Security Testing

  1. Difference between SAST and DAST, black box testing on the running application

  2. The DAST scan flow, crawling, fuzzing, response analysis

  3. Overview of DAST tools (e.g. OWASP ZAP, Burp Suite)

  4. Practical exercise: run a DAST scan on a vulnerable test application (e.g. OWASP Juice Shop), identify and validate the findings

SCA – Software Composition Analysis

  1. Risk of third-party dependencies and libraries, inherited vulnerabilities

  2. SBOM, Software Bill of Materials, what it is and why it matters

  3. Overview of SCA tools (e.g. Dependency Check, Snyk, GitHub Dependabot)

  4. Practical exercise: run an SCA scan on a real project, identify vulnerable dependencies and build a remediation plan (update, patch, mitigate)

Requirements

Participants should have:

  • Basic knowledge of software development concepts
  • Basic understanding of web applications and common web technologies
  • Familiarity with the Software Development Lifecycle (SDLC)
  • Basic understanding of source code and software dependencies
  • Basic knowledge of security concepts is beneficial, but not mandatory

Target Audience

  • Software Developers
  • Software Engineers
  • QA and Software Test Engineers
  • DevOps and DevSecOps Engineers
  • Application Security Professionals
  • Security Engineers
  • Software Architects
  • Technical Leads
  • Professionals involved in secure software development and application security testing
 21 Hours

Number of participants


Price per participant

Testimonials (3)

Upcoming Courses

Related Categories