AppSec Training & Awareness
Why cloud development needs its own awareness
A developer who has only ever shipped to a corporate data center carries one assumption into the cloud that quietly breaks everything: that the network is a trust boundary. On-premises, an application could lean on the firewall, treat any caller already inside the perimeter as friendly, and keep a database password in a config file on a server nobody outside could reach. In the cloud none of that holds, and awareness training exists to retrain exactly these instincts before they become code.
What actually changes
Three shifts matter for everyone who writes cloud code. First, the perimeter dissolves: a workload is reachable through public control-plane and data-plane APIs, so an internal source address is no longer authorization and every call must be authenticated. Second, secrets travel: credentials now move through source repositories, CI/CD pipelines, container images, and environment variables, any of which can leak them, so they belong in a managed secrets store and never in code. Third, identity is the new blast radius: a single over-permissive IAM[1] role attached to a function or container can, if the code is compromised, hand an attacker everything that role can reach, so least privilege is a coding concern, not just an ops one.
Cloud development basics, stated as habits
The basics CCSP expects a developer to internalize reduce to a few habits. Assume the network gives you nothing and authenticate every request. Keep secrets out of code and out of images, fetching them at runtime from a secrets manager. Validate and encode all input and output, because the data plane is now exposed directly. Pin and scan dependencies, because most cloud applications are mostly other people's code. And design each component to run with the minimum permissions it needs. The detailed, phase-by-phase practice of building these in lives in the secure SDLC process and applying the secure SDLC subtopics; awareness is making sure the habit is there before the first commit.
The OWASP Top 10: the awareness catalog of web app risks
When CCSP asks what to teach developers, the OWASP Top 10 is the canonical answer for web application risk. It is a community-built, periodically-updated list of the ten most critical risk categories, ranked from data on how often each appears and how exploitable it is across many real applications. It is deliberately a list of broad risk categories, not individual bugs, which is what makes it a teaching tool: a developer who understands the ten categories can reason about a new flaw by where it fits.
The 2021 categories you should recognize
The current edition is the OWASP Top 10:2021[2], and the headline change matters for the exam: Broken Access Control rose to the number one risk.
- A01 Broken Access Control rose to first; a user reaching data or actions they are not authorized for. The most common serious web flaw in the underlying data.
- A02 Cryptographic Failures (formerly Sensitive Data Exposure); weak or missing encryption of data in transit or at rest, exposing sensitive data.
- A03 Injection; untrusted input interpreted as a command or query, which now includes cross-site scripting (XSS) folded into this category.
- A04 Insecure Design, a category introduced in 2021; flaws that come from missing or weak security design rather than a coding mistake, which is why threat modeling matters.
- A05 Security Misconfiguration; insecure defaults, unnecessary features enabled, verbose error messages. The category that maps most directly to cloud breaches.
- A06 Vulnerable and Outdated Components; running libraries or platforms with known vulnerabilities, the dependency-risk category.
- A07 Identification and Authentication Failures; weak credentials, broken session management, missing MFA.
- A08 Software and Data Integrity Failures, new in 2021; trusting code, updates, or CI/CD pipelines without verifying integrity, the category that captures supply-chain attacks.
- A09 Security Logging and Monitoring Failures; not detecting or responding to a breach because the evidence was never captured.
- A10 Server-Side Request Forgery (SSRF), new in 2021; the application is tricked into making requests to unintended internal targets, a risk that grew sharply with cloud metadata endpoints.
For awareness you teach the categories and their cloud relevance; the secure coding that closes them is the work of applying the secure SDLC. Note the cloud accents: A05 misconfiguration and A10 SSRF both became more dangerous specifically because of how cloud platforms expose configuration and internal metadata services.
CWE/SANS Top 25: from risk category down to the exact weakness
The OWASP Top 10 tells a developer which risks to worry about; the CWE/SANS Top 25 tells them the precise weakness underneath. The crucial distinction the exam tests is grain. CWE (Common Weakness Enumeration)[3], maintained by MITRE, is a dictionary of individual software weakness types, each with a stable identifier such as CWE-79 or CWE-89. The CWE Top 25 Most Dangerous Software Weaknesses[4] ranks the 25 most prevalent and severe of these, scored from how often they appear in reported CVEs and how damaging they are. The list was historically published with SANS, which is why it is still called the CWE/SANS Top 25.
How the two catalogs relate
Think of them as two zoom levels on the same problem, not rivals. An OWASP risk category contains several CWE weaknesses: OWASP A03 Injection covers CWE-89 (SQL injection) and CWE-79 (cross-site scripting); OWASP A01 Broken Access Control covers weaknesses such as CWE-22 (path traversal) and CWE-862 (missing authorization). OWASP is the awareness framing for prioritizing what to teach and test; CWE is the precise label you attach to a specific finding so it can be tracked, deduplicated, and trained against. A useful exam reflex: if a stem names a broad risk, it is pointing at OWASP; if it gives a specific weakness or a CWE-number, it is pointing at the CWE Top 25.
A few weaknesses worth recognizing by name
Candidates should recognize the perennial leaders without memorizing the whole ranking: out-of-bounds write (CWE-787) and out-of-bounds read (CWE-125) for memory-safety bugs, cross-site scripting (CWE-79), SQL injection (CWE-89), and use-after-free (CWE-416). The exact ordering shifts year to year, so the exam-durable knowledge is the kind of weakness each names and which OWASP category it rolls up into, not its current rank.
Common cloud-dev pitfalls and how to read the question
Most cloud application breaches are not exotic; they are a short list of recurring mistakes, and the value of awareness training is that a developer recognizes each by its symptom and reaches for the right one-line defense. Match the pitfall to its fix, and you are reading the exam stems the way they are written.
The recurring pitfalls, each with its defense
- Hardcoded secrets. API keys, database passwords, or tokens committed to source or baked into a container image. The defense is a secrets manager that the app reads at runtime, plus pre-commit and pipeline secret scanning. Because a commit is permanent, the moment a secret is exposed you rotate it, not just delete the commit; the history still holds it.
- Insecure defaults / misconfiguration. A storage bucket left public, debug mode on in production, a default admin password unchanged. This is OWASP A05 and the single most common cloud-breach root cause. The defense is hardened baselines (for example a CIS Benchmark) applied from a golden image, plus configuration scanning that flags drift.
- Over-permissive IAM. A function or container granted a wildcard or admin role because it was easier than scoping it. The defense is least privilege: grant only the actions and resources the component needs, and prefer short-lived credentials over long-lived keys.
- Unvalidated input. Trusting data from a request, a queue, or another service, which is the root of the whole injection family. The defense is to validate input against an allowlist and encode output for its context; awareness names it, and the secure-coding subtopic implements it.
- Vulnerable dependencies. Shipping a library with a known CVE, which is OWASP A06. The defense is software composition analysis (SCA) in the pipeline and keeping components current.
Reading the stem
The pattern recognition that pays off: a scenario about data exposed with no exploit and no malware points to misconfiguration and the hardened-baseline answer, not a new firewall. A credential found in a repository or image points to the secrets-manager-and-rotation answer. A compromised function that reached far more than it should have points to over-permissive IAM and least privilege. A stem that names a specific weakness or CWE number points to the CWE Top 25; one that names a broad risk points to the OWASP Top 10. When a question describes the symptom, match it to the concept rather than to the most technically impressive-sounding option, which is usually the distractor. The hands-on remediation for each of these is built in applying the secure SDLC and validated in software assurance and validation.
OWASP Top 10 vs CWE/SANS Top 25: the two awareness catalogs
| Aspect | OWASP Top 10 (2021) | CWE/SANS Top 25 |
|---|---|---|
| What it lists | The 10 most critical web application security risks, as broad risk categories | The 25 most dangerous software weaknesses, as specific CWE entries |
| Grain | Risk categories (e.g. Broken Access Control, Injection) | Individual weaknesses (e.g. CWE-79 XSS, CWE-89 SQL injection) |
| Maintained by | OWASP, a software-security community | MITRE (CWE), historically with SANS |
| How ranked | Data on incidence and exploitability across many applications | Prevalence and severity scored across reported CVEs |
| Best used for | Framing app-risk awareness and prioritizing testing | Pinning the exact weakness behind a risk and developer training |
| Top entry | A01 Broken Access Control (rose to #1 in 2021) | Out-of-bounds write and the injection family lead recent lists |
Decision tree
Sharp facts the exam loves — give these one last read before exam day.
Cheat sheet
Sharp facts the exam loves — scan these before test day.
- The OWASP Top 10 and CWE/SANS Top 25 are the two awareness catalogs CCSP grades against
When the exam asks what application-security awareness training should reference, the answer is the OWASP Top 10 for web application risk categories and the CWE/SANS Top 25 for the underlying software weaknesses. The two are zoom levels on one problem, not competitors: OWASP frames broad risks for prioritization, while CWE names the exact weakness so it can be tracked and trained against.
- OWASP lists broad risk categories; CWE lists specific weaknesses
The OWASP Top 10 entries are broad risk categories such as Broken Access Control or Injection, ten of them, ranked by incidence and exploitability across many applications. The CWE Top 25 entries are individual weakness types with stable identifiers, such as CWE-79 (cross-site scripting) or CWE-89 (SQL injection), ranked by how often they appear in reported CVEs and how severe they are. A stem that names a broad risk points to OWASP; one that gives a specific weakness or a CWE number points to the CWE Top 25.
Trap Treating OWASP and CWE as the same granularity; OWASP is risk categories, CWE is individual weakness identifiers, and a question can hinge on that distinction.
- Broken Access Control rose to the #1 OWASP risk in 2021
In the OWASP Top 10:2021, A01 Broken Access Control became the top-ranked risk, displacing Injection, because the supporting data showed it was the most common serious flaw across tested applications. It means a user reaching data or actions they are not authorized for.
Trap Naming Injection as the current #1 OWASP risk; it led in 2017 but Broken Access Control overtook it in the 2021 edition.
- OWASP 2021 folded XSS into the Injection category
Cross-site scripting is no longer its own OWASP Top 10 entry; in the 2021 edition it sits inside A03 Injection alongside SQL injection and command injection, because all share the root cause of untrusted input being interpreted. As a CWE it is still CWE-79.
Trap Expecting a standalone Cross-Site Scripting entry in the OWASP Top 10:2021; XSS was merged into A03 Injection that edition.
- Insecure Design (A04) is the OWASP category for missing security design, not coding bugs
A04 Insecure Design was introduced in 2021 to capture flaws that come from weak or absent security design rather than an implementation mistake, which is why threat modeling and secure design patterns are its countermeasures. A perfectly coded feature can still be insecure by design if the design never considered the threat.
Trap Assuming better code review or testing fixes Insecure Design; the flaw is in the design, so it is addressed by threat modeling and secure design, not by catching bugs.
- SSRF (A10) and Misconfiguration (A05) are the OWASP risks the cloud sharpens most
Server-Side Request Forgery was added as A10 in 2021 partly because cloud metadata endpoints make a tricked internal request especially damaging, exposing instance credentials. Security Misconfiguration (A05) is the OWASP category that maps most directly to cloud breaches, because insecure defaults and exposed configuration are the dominant cloud failure. Both are general risks, but cloud raises their impact.
Trap Dismissing SSRF as a niche web bug in a cloud context; against a metadata endpoint it can leak the instance's IAM credentials.
- CWE is MITRE's dictionary of weakness types; the Top 25 ranks the most dangerous
Common Weakness Enumeration (CWE) is maintained by MITRE as a catalog of software and hardware weakness types, each with a stable CWE-number. The CWE Top 25 Most Dangerous Software Weaknesses ranks the 25 most prevalent and severe, scored from reported CVE data. It was historically co-published with SANS, which is why it is still called the CWE/SANS Top 25.
- An OWASP category contains several CWE weaknesses
The two catalogs nest: OWASP A03 Injection contains CWE-89 (SQL injection) and CWE-79 (cross-site scripting); OWASP A01 Broken Access Control contains weaknesses such as CWE-22 (path traversal) and CWE-862 (missing authorization). OWASP is the awareness framing for prioritizing what to teach; CWE is the precise label you attach to a specific finding so it can be tracked and deduplicated.
- The cloud dissolves the network as a trust boundary, so authenticate every call
Cloud workloads are reachable through public control-plane and data-plane APIs, so an internal source address is no longer authorization. Code that trusted any caller already inside the data center must be rewritten to authenticate and authorize every request, because the perimeter the old code leaned on does not exist in the cloud.
Trap Relying on network position or a VPC boundary to authorize requests between cloud services; location grants no trust, so each call still needs its own authentication.
- Keep secrets out of code and images; fetch them from a secrets manager at runtime
In the cloud, credentials travel through source repositories, CI/CD pipelines, container images, and environment variables, any of which can leak them. The awareness rule is that secrets belong in a managed secrets store the app reads at runtime, never hardcoded in source or baked into an image. This is the developer-side habit; OWASP catalogs the failure as part of misconfiguration and integrity risks.
Trap Storing a secret in an environment variable or container image and treating it as hidden; both are readable and leak the credential.
2 questions test this
- Misconfiguration and insecure defaults are the most common cloud-breach root cause
A publicly exposed storage bucket, debug mode left on in production, or a default admin password unchanged is consistently the largest single source of cloud breaches, and it is OWASP A05 Security Misconfiguration. The defense taught in awareness is hardened baselines (for example a CIS Benchmark) deployed from a golden image, plus configuration scanning that flags drift. When a scenario shows data exposed with no exploit or malware, this is the root cause.
Trap Reaching for a new firewall or perimeter device when data is exposed with no exploit; the cause is misconfiguration, fixed by a hardened baseline, not a network control.
- Over-permissive IAM turns a compromised component into a full-account compromise
A function or container granted a wildcard or admin role hands an attacker everything that role can reach if the code is compromised, so least privilege is a coding and design concern, not just an operations one. Grant each component only the actions and resources it needs, and prefer short-lived credentials over long-lived static keys. A stem where a compromised component reached far more than its job required points here.
Trap Attaching a broad or admin role to a workload because scoping it is more effort; one compromise then exposes everything that role can reach.
2 questions test this
- Unvalidated input is the root of the entire injection family
Trusting data from a request, a queue, or another service is what lets untrusted input be interpreted as a command or query, which is OWASP A03 Injection. The awareness-level defense is to validate input against an allowlist and encode output for its context. Awareness names the weakness; the secure-coding subtopic implements the parameterized query and the encoder.
Trap Validating only with a denylist of known-bad patterns; attackers bypass denylists, so an allowlist of permitted input is the durable control.
7 questions test this
- An organization is developing a security awareness training program for developers to address OWASP Top 10 vulnerabilities. According to…
- An organization is developing a security awareness program for their development team focused on preventing injection vulnerabilities.…
- A development team is implementing secure coding practices according to the NIST Secure Software Development Framework (SSDF). Which…
- A development team is building an event-driven application that consumes messages from an event bus. According to OWASP guidance, which…
- A development team is building a serverless application that can be triggered by multiple event sources including API Gateway requests,…
- An organization is evaluating security risks specific to their event-driven serverless architecture. A security analyst identifies that…
- According to OWASP secure coding practices, which of the following represents the MOST critical practice for preventing injection…
- Vulnerable and outdated dependencies (A06) need software composition analysis
Most cloud applications are mostly other people's code, so shipping a library or platform with a known CVE is a leading risk, catalogued as OWASP A06 Vulnerable and Outdated Components. The awareness-level defense is software composition analysis (SCA) in the pipeline to detect known-vulnerable dependencies, plus keeping components current.
Trap Assuming your own code review covers third-party libraries; SCA tooling, not manual review, is what finds known-vulnerable dependencies at scale.
- Awareness names the weakness and the defense; secure coding implements it
AppSec training and awareness is the what and the why: which weaknesses exist, why the cloud makes them sharper, and how to recognize them in a question stem. The hands-on secure coding, threat modeling, and SDLC-phase work belong to the secure SDLC subtopics. On the exam, a question about recognizing a risk category or a common pitfall is awareness; a question about how to implement the fix is the secure SDLC.
- Role-based awareness training is most effective before the first commit
Secure software depends more on what developers know going in than on what testing catches coming out, because the cheapest defect to fix is the one never written. Awareness training therefore targets onboarding and is role-based, so developers, testers, and operators each learn the pitfalls relevant to their work before insecure code or defaults enter the repository.
- Match the symptom to the awareness answer when reading the stem
The recurring pattern: data exposed with no exploit points to misconfiguration and a hardened baseline; a credential found in a repo or image points to a secrets manager plus rotation; a compromised component that reached too far points to over-permissive IAM and least privilege. Match the described symptom to the concept rather than to the most technically impressive option, which is usually the distractor.
References
- NIST Glossary — Identity and Access Management (IAM): definition used for the least-privilege / blast-radius framing
- OWASP Top 10 — the canonical list of the most critical web application security risks (2021 edition: A01 Broken Access Control to A10 SSRF)
- MITRE CWE — Common Weakness Enumeration, the community dictionary of software and hardware weakness types (stable CWE-N identifiers)
- MITRE CWE Top 25 Most Dangerous Software Weaknesses — ranked by prevalence and severity from reported CVE data (historically the CWE/SANS Top 25)