Course Outline
A01:2025 – Broken Access Control
Access control mechanisms enforce operational policies to ensure personnel act strictly within their authorized permissions. Deficiencies in these controls typically result in unauthorized disclosure, alteration, or destruction of data, or the execution of business functions beyond the user’s defined authority limits.
Practical Aspects
-
Illustrative examples of broken access controls in government systems
-
Secure access control frameworks and best practices for public sector compliance
A02:2025 – Security Misconfiguration
Security misconfiguration occurs when a system, application, or cloud service is improperly configured from a security perspective, thereby introducing vulnerabilities that compromise integrity and availability.
Practical Aspects
-
Real-world examples of misconfigurations affecting public infrastructure
-
Procedures to prevent misconfiguration, including configuration management and automation tools for government environments
A03:2025 – Software Supply Chain Failures
Software supply chain failures represent breakdowns or compromises in the processes of building, distributing, or updating software. These incidents are frequently caused by vulnerabilities or malicious modifications in third-party code, tools, or dependencies that public sector systems rely upon.
A04:2025 – Cryptographic Failures
Generally, all data in transit must be encrypted at the transport layer (OSI layer 4). Historical challenges related to CPU performance and private key/certificate management have been mitigated by modern CPUs featuring instructions designed to accelerate encryption (e.g., AES support) and by the simplification of key management through services like LetsEncrypt.org, with major cloud vendors offering tightly integrated certificate management solutions for their platforms.
Beyond securing the transport layer, it is critical to determine which data requires encryption at rest and which necessitates additional encryption during transmission (at the application layer, OSI layer 7).
For instance, passwords, financial identifiers, health records, personally identifiable information, and proprietary business secrets require enhanced protection, particularly when such data is subject to privacy laws, such as the EU’s General Data Protection Regulation (GDPR), or regulations like the PCI Data Security Standard (PCI DSS).
Practical Aspects
-
Detailed analysis of cryptographic failures, including weak encryption algorithms or improper key management, in the context of government data protection
-
The importance of robust cryptographic mechanisms, secure protocols (SSL/TLS), and examples of modern cryptography in web security for government applications
A05:2025 – Injection
An injection vulnerability is a systemic flaw that permits 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 these inputs as if they were native system commands. This can lead to severe operational and security consequences.
Practical Aspects
-
A detailed breakdown of SQL, NoSQL, OS, and LDAP injection vectors relevant to government software
-
Mitigation techniques using prepared statements, parameterized queries, and input escaping for secure government development
A06:2025 – Insecure Design
Insecure design is a broad category representing various weaknesses, characterized by “missing or ineffective control design.”
Insecure design is distinct from the root cause of other Top Ten risk categories. It is essential to differentiate between design flaws and implementation defects, as they possess different root causes, occur at different stages of the development lifecycle, and require distinct remediation strategies.
A secure design may still exhibit implementation defects that lead to exploitable vulnerabilities. Conversely, an insecure design cannot be remediated by a flawless implementation because the necessary security controls were never established to defend against specific attacks.
A key factor contributing to insecure design is the lack of business risk profiling inherent in the software or system, resulting in an inability to determine the requisite level of security design for government operations.
Practical Aspects
-
Exploration of design flaws that lead to vulnerabilities, such as improper input validation, with a focus on government compliance
-
Strategies for secure architecture and secure design principles applicable to public sector systems
A07:2025 – Authentication Failures
This vulnerability exists when an attacker can manipulate a system into recognizing an invalid or unauthorized user as legitimate, thereby bypassing identity verification controls.
Practical Aspects
-
Common authentication issues in government digital identity systems
-
Secure authentication strategies, including multi-factor authentication and proper session handling, to protect government assets
A08:2025 – Software or Data Integrity Failures
Software and data integrity failures involve code and infrastructure that fail to prevent invalid or untrusted code or data from being treated as trusted and valid.
An example is when an application relies upon plugins, libraries, or modules from untrusted sources, repositories, or content delivery networks (CDNs), which poses risks for government systems.
An insecure CI/CD pipeline that lacks software integrity checks can introduce the potential for unauthorized access, the insertion of insecure or malicious code, or full system compromise.
Another example is a CI/CD process that retrieves code or artifacts from untrusted locations and fails to verify them before use (e.g., by checking signatures or similar mechanisms).
Practical Aspects
-
Focus on issues like untrusted software updates and data tampering in government software lifecycles
-
Safe update mechanisms and data integrity checks to ensure the trustworthiness of government digital services
A09:2025 – Security Logging and Alerting Failures
Without comprehensive logging and monitoring, attacks and breaches remain undetected. Furthermore, without effective alerting, it is exceedingly difficult to respond quickly and effectively during a security incident.
Insufficient logging, continuous monitoring, detection, and alerting capabilities hinder the initiation of active responses when necessary.
Practical Aspects
-
The importance of logging security-relevant information and monitoring for suspicious activities in accordance with government accountability standards
-
Tools and practices for proper logging and real-time monitoring to detect breaches early in government networks
A10:2025 – Mishandling of Exceptional Conditions
Mishandling exceptional conditions in software occurs when programs fail to prevent, detect, and respond to unusual and unpredictable situations, leading to crashes, unexpected behavior, and potential vulnerabilities.
This can involve one or more of the following three failings:
-
The application does not prevent an unusual situation from occurring
-
The system fails to identify the situation as it occurs
-
The application responds inadequately or not at all to the situation afterward
SAST – Static Application Security Testing
-
Definition of static analysis and its integration into the SDLC (shift-left approach) for government software development
-
Types of vulnerabilities detectable through SAST, comparing vulnerable code versus secure code
-
Overview of SAST tools (e.g., Semgrep, SonarQube, Checkmarx), selected based on the government technology stack
-
Practical exercise: Execute a SAST scan on a repository with intentionally introduced vulnerabilities, interpret results, and triage false positives versus real vulnerabilities
DAST – Dynamic Application Security Testing
-
Differences between SAST and DAST, focusing on black-box testing of running applications
-
The DAST scan workflow, including crawling, fuzzing, and response analysis
-
Overview of DAST tools (e.g., OWASP ZAP, Burp Suite) for assessing government web applications
-
Practical exercise: Perform a DAST scan on a vulnerable test application (e.g., OWASP Juice Shop) and identify and validate findings
SCA – Software Composition Analysis
-
Risks associated with third-party dependencies and libraries, including inherited vulnerabilities
-
SBOM (Software Bill of Materials): Definition and significance for government supply chain transparency
-
Overview of SCA tools (e.g., Dependency Check, Snyk, GitHub Dependabot) for government use
-
Practical exercise: Run an SCA scan on a real project, identify vulnerable dependencies, and construct 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 for government
Testimonials (3)
Experience sharing, it's teacher's know-how and valuable.
Carey Fan - Logitech
Course - C/C++ Secure Coding
get to understand more about the product and some key differences between RHDS and open source OpenLDAP.
Jackie Xie - Westpac Banking Corporation
Course - 389 Directory Server for Administrators
the knowledge of the trainer was very high - he knew what he was talking about, and knew the answers to our questions
