Application and product security engineers help teams meet security obligations by translating them into design decisions, tests, operational controls, and evidence. The exact obligations depend on the product, data, customers, contracts, and countries involved; this guide is educational, not legal advice.
1. First, distinguish the terms
- Law or regulation: legally binding requirements when the organization, product, data, and activity are in scope.
- Standard: a published set of requirements or guidance. Some standards support an organization's certification; they do not certify an individual engineer or guarantee secure software.
- Framework: a way to organize risk-management or engineering practices. Framework use may be voluntary unless incorporated into a contract, policy, or regulation.
- Assurance report: evidence about an organization's controls and a defined audit scope and period. It is not the same as a product security certification.
CAREER PATH · LEVEL 1
2. Security foundations: networks, systems, and risk
Learning goal: understand security language, identity, configuration, and basic risk. At this stage, learn what the frameworks are for; you are not expected to certify systems or interpret legal scope by yourself.
| Reference | How it fits Level 1 | What to learn |
|---|---|---|
| NIST Cybersecurity Framework (CSF) 2.0 | A voluntary framework for managing cybersecurity risk. | Recognize Govern, Identify, Protect, Detect, Respond, and Recover as organization-wide outcomes. Use the CSF to understand risk conversations; it is not a step-by-step technical checklist or certification. |
| CIS Benchmarks | Consensus-based secure-configuration recommendations for operating systems, cloud services, and other technologies. | Learn why secure baselines, least privilege, patching, and configuration review matter. A benchmark is guidance; test settings before applying them and document approved exceptions. |
| NIST SP 800-53 | A broad catalog of security and privacy controls used by organizations and systems with different risk profiles. | Recognize control families such as access control, audit, configuration management, incident response, and system protection. The organization selects and tailors controls; do not treat the catalog as a checklist that applies identically to every product. |
| NIST SP 800-63B | Guidance for digital identity authentication and authenticator management. | Understand authentication factors, phishing-resistant options, account recovery, and why authentication is different from authorization. Use current organizational policy and platform guidance rather than inventing password rules. |
Networking connection: network segmentation, firewall rules, protected management access, and logging support many controls, but no single network design makes a system compliant.
CAREER PATH · LEVEL 2
3. Application and API security
Learning goal: translate risk categories into requirements and negative tests for web and API behavior. Use vulnerability lists as a map of common failure modes, not a complete audit or a guarantee of security.
| Reference | How it fits Level 2 | What to practice |
|---|---|---|
| OWASP Top 10 | Awareness categories for important web-application risks. | Connect broken access control, injection, misconfiguration, vulnerable components, and other categories to concrete design and test cases. It is not an exhaustive security standard. |
| OWASP API Security Top 10 | Awareness categories focused on API risks. | Practice object-, property-, and function-level authorization; authentication; rate limits; inventory; and safe dependency use. Test with multiple roles and tenants using synthetic data. |
| OWASP Application Security Verification Standard (ASVS) | A structured set of verifiable security requirements for web applications. | Use its applicable requirements to make reviews and tests specific. Choose a suitable scope and verification level with the team; do not claim conformance based on a few passing checks. |
| MITRE CWE | A community-developed classification of software weakness types. | Use weakness names to describe root causes precisely and connect findings to secure coding and regression tests; a CWE identifier alone does not describe exploitability or risk. |
Privacy and sector rules such as GDPR, HIPAA, and payment requirements may constrain an application at any level. Applicability depends on the product, data, organization, and jurisdiction; they are not automatically triggered by using a particular technology.
CAREER PATH · LEVEL 3
4. Product security and organizational assurance
Learning goal: help teams turn obligations into lifecycle controls, owners, evidence, and sustained vulnerability response. This is where secure-development frameworks, management-system standards, customer assurance, and domain-specific obligations meet engineering practice.
| Reference | What it is | What to know as an engineer |
|---|---|---|
| NIST Secure Software Development Framework (SSDF) | Software-development practices published as NIST SP 800-218. | Connect team preparation, software protection, secure releases, and vulnerability response to actual workflows, tests, and release evidence. The SSDF is guidance, not a certification. |
| ISO/IEC 27001:2022 and ISO/IEC 27002 | 27001 specifies requirements for an information security management system (ISMS); 27002 provides information-security control guidance. | Expect risk ownership, defined processes, access control, supplier and incident practices, internal audit, and continual improvement. Certification applies to the organization's system and scope; it does not mean every application is vulnerability-free. The full standard text may require purchase. |
| SOC 2 | An independent CPA attestation engagement using the AICPA Trust Services Criteria; it is not a government regulation or a certification. | Product teams often supply evidence for access reviews, secure changes, vulnerability handling, incidents, and vendors. Type I evaluates control design at a point in time; Type II also evaluates operation over a period. Follow the audit scope and evidence requests. |
| PCI DSS | Industry security requirements for entities and systems in scope for payment account data. | Determine whether a system stores, processes, transmits, or can affect the security of account data. Scope and segmentation matter. Coordinate interpretation and evidence with the organization's PCI lead or qualified assessor. |
| GDPR | A European Union regulation on processing personal data, where its territorial and material scope applies. | Know the engineering implications of data minimization, purpose and retention limits, privacy by design and default, access controls, data-subject requests, and breach-response processes. Privacy and legal teams determine applicability and obligations. |
| HIPAA Security Rule | U.S. requirements for protecting electronic protected health information (ePHI) held by covered entities and business associates, where the rule applies. | Understand the administrative, physical, and technical safeguard areas, including access, audit, integrity, authentication, and transmission protections. The organization determines whether it is in scope. |
CAREER PATH · LEVEL 4
5. AI application security and governance
Learning goal: manage AI-specific risks across models, prompts, retrieval, tools, identities, datasets, and providers while retaining the software and privacy controls from earlier levels.
| Reference | What it is | What to know as an engineer |
|---|---|---|
| NIST AI Risk Management Framework (AI RMF) | Voluntary guidance for managing risks from the design through use of AI systems. | Learn Govern, Map, Measure, and Manage. Keep system boundaries, intended uses, evaluations, limitations, human oversight, and monitoring connected. NIST notes that AI RMF 1.0 is under revision; check the official page for current material. |
| ISO/IEC 42001:2023 and ISO/IEC 23894:2023 | 42001 specifies an AI management system; 23894 provides guidance on AI risk management. | Understand organizational roles, impact and risk assessment, lifecycle controls, documentation, monitoring, and improvement. A management-system certification is about the organization's system and scope—not proof that a particular model cannot fail. |
| EU Artificial Intelligence Act | An EU regulation that establishes obligations based on AI system risk, intended use, and the role of providers, deployers, and other parties. | For an AI feature, capture its intended purpose, users, data flows, human oversight, logging, and system role early. Applicability and duties are context-dependent and phase in over time; verify the current official timeline with the organization's legal and compliance teams. |
| OWASP Top 10 for LLM Applications | A risk-awareness resource for generative-AI applications. | Use it to develop test cases for prompt injection, sensitive-data disclosure, insecure output handling, excessive agency, and other LLM-specific risks. It is not a regulation or a complete threat model. |
| MITRE ATLAS and CSA MAESTRO resources | ATLAS catalogs adversary tactics and techniques against AI systems; MAESTRO is CSA's seven-layer threat-modeling approach for agentic AI. | Use ATLAS for adversary-informed scenarios and MAESTRO to structure threats across agentic-system layers. Neither is a certification, a law, or a substitute for system-specific analysis. |
Level 4 builds on Levels 1–3; AI does not replace ordinary identity, data-protection, secure-development, and incident-response requirements.
6. Cross-cutting threat frameworks are not compliance
These tools help teams reason about threats and tests. Use them alongside applicable laws, contracts, standards, and organizational policies—not in place of them.
- OWASP Top 10 and the OWASP API Security Top 10 are awareness lists for web and API risk, not complete compliance checklists.
- OWASP Top 10 for LLM Applications highlights generative-AI application risks; it does not replace a system-specific threat model.
- MITRE ATT&CK organizes observed adversary tactics and techniques for enterprise environments.
- MITRE ATLAS organizes adversary tactics and techniques targeting AI-enabled systems.
- STRIDE is a threat-modeling mnemonic: spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege.
- Cloud Security Alliance AI security resources — use the CSA's current hub for MAESTRO (Multi-Agent Environment, Security, Threat, Risk, and Outcome), a seven-layer threat-modeling approach for agentic AI systems; it is not a compliance standard.
7. What an application and product security engineer should do
- Ask which customer, legal, privacy, contractual, or payment-data requirements actually apply to this product and its deployment.
- Translate each applicable requirement into a named owner, product control, test, and evidence source.
- Build security into design and delivery: authorization tests, threat models, dependency and secret checks, secure release controls, and monitored response paths.
- For APIs, verify object-level and tenant-level authorization, data minimization, rate limits, and audit events.
- For AI, document intended use and data flows; test retrieval isolation, output handling, tool permissions, human review, model changes, and incident paths.
- Keep evidence accurate and scoped. Don't claim “compliant” or “certified” based only on a scan, framework mapping, or a control working in one test.
Learn how to read a requirement, find the engineering control behind it, write a test for that control, and explain what evidence demonstrates it. You do not need to memorize every clause or act as the organization's lawyer or auditor.
8. Free learning resources
- NIST SSDF — start here for secure software lifecycle practices.
- NIST CSF 2.0 — learn the shared language for organizational cyber-risk outcomes.
- OWASP SAMM — explore a model for improving software assurance activities.
- NIST AI RMF Playbook — use the official AI RMF page to reach the current playbook and resources.
- PCI Security Standards Council document library and the official GDPR text — consult primary sources when those scopes apply.
Practice mapping a technical finding to evidence
- PortSwigger Web Security Academy — complete a free, in-scope web security lab, then document the affected asset, risk, control objective, remediation owner, retest evidence, and residual risk. A training lab does not establish compliance.
- TryHackMe: OWASP Top 10 — use an authorized training room to practice explaining a vulnerability and its remediation; check current free access and room availability.
- HTB Academy catalogue — search for currently available web, risk, or cloud security modules and map one lab finding to a security requirement.
Watch governance and compliance playlists
- IBM Technology: AI Ethics and Governance Explained — accessible governance concepts from a channel with approximately 1.81M subscribers; this is an introduction, not compliance training.
Subscriber counts are approximate and change over time; video view counts vary. No single high-audience playlist covering the standards in this guide was verified; consult the official framework sources above for requirements.
Some standards' full texts and audit criteria are copyrighted or available only through paid sources. Use official summaries and your organization's approved copies; don't rely on unofficial reproductions.