ISO/IEC 27034 Lead Application Security Implementer key terms

The set of practices, controls, and processes that protect software applications from threats throughout their lifecycle, covering design, coding, testing, deployment, operation, and retirement of the application.

The organized framework of processes, roles, policies, and records an organization uses to govern application security consistently, providing structure for planning, implementing, verifying, and improving controls across all applications.

The three core information security objectives: keeping data accessible only to authorized parties, keeping it accurate and unaltered, and keeping it usable when needed. Application security controls are typically justified by which of these they protect.

Any potential cause of harm to an application or its data, such as an attacker, malicious code, or a natural event. Threats are assessed together with vulnerabilities and impact to determine risk.

A weakness in an application's design, code, configuration, or dependencies that a threat could exploit to cause harm. Vulnerabilities are identified through reviews, testing, and scanning and then prioritized for remediation.

A technique, input, or tool that takes advantage of a vulnerability to achieve an unintended effect, such as data disclosure or code execution. The existence of a working exploit typically raises the assessed severity of a vulnerability.

The total set of entry points and exposed resources through which an attacker could interact with an application, including interfaces, endpoints, credentials, and third-party integrations. Reducing it limits opportunities for exploitation.

The process of identifying, analyzing, and evaluating risk by combining threat likelihood, vulnerability exposure, and potential impact. Its output guides which application security controls to prioritize and how much effort to invest.

A design principle of layering multiple independent controls so that failure of one does not leave the application unprotected. Layers commonly span the network, host, application, and data levels.

The principle that users, processes, and components receive only the permissions strictly needed to perform their function, for no longer than necessary. It limits the damage an attacker or a bug can cause.

A safeguard or countermeasure applied to reduce risk, implemented as a technical mechanism, a process, or an organizational measure. Controls are selected during planning, applied during implementation, and checked during verification.

The activity of defining scope, objectives, roles, controls, and acceptance criteria for securing an application before and during development. It aligns security work with business risk and project timelines.

Documented, verifiable statements describing what an application must do or avoid to meet its security objectives. They translate risk decisions and obligations into testable criteria for design and acceptance.

A structured analysis performed during design that identifies assets, entry points, threats, and mitigations for an application. It produces a prioritized list of risks that shapes architecture and security requirements.

The arrangement of an application's components, trust boundaries, and controls that together achieve its security objectives. It documents how authentication, authorization, data protection, and logging are positioned and integrated.

A line in a system where data or control passes between components with different levels of trust, such as between a browser and a server. Controls such as validation and authentication are placed at these boundaries.

The decision and action taken in response to assessed risk: mitigate with controls, transfer, avoid the activity, or accept the residual risk with accountability. The chosen option is recorded and revisited as conditions change.

The risk that remains after controls have been applied. It must be explicitly accepted by an accountable owner, because no set of controls eliminates all risk.

Predefined, measurable conditions that a deliverable must satisfy to be approved, including security conditions. Clear criteria let reviewers decide objectively whether a control or feature is complete.

An approach that embeds security activities such as requirements analysis, threat modeling, secure coding, and security testing into each phase of software development rather than adding them at the end.

A documented set of rules and practices developers must follow to avoid common weakness patterns, such as unsafe input handling or hard-coded secrets. It gives reviewers and tools an objective basis for judging code.

The control that checks incoming data against expected type, format, length, and range before the application uses it. Allow-list validation is preferred because it rejects anything not explicitly permitted.

The control that converts data into a safe representation for its destination context, such as HTML, SQL, or JavaScript, so that data is not interpreted as executable code. It complements, but does not replace, input validation.

A class of attack in which untrusted data is interpreted as commands or code by an interpreter such as a database or shell. Parameterized queries and context-aware encoding are the primary defenses.

The process of verifying that a claimed identity is genuine, typically through credentials, tokens, or cryptographic proofs. Weak authentication undermines every authorization decision that depends on it.

The process of deciding whether an authenticated subject may perform a requested action on a resource. It is enforced server-side on every request, following least privilege and explicit deny rules.

The mechanisms that enforce authorization decisions, such as role-based or attribute-based policies applied at each resource. Effective access control prevents users from reaching data or functions outside their granted scope.

Authentication requiring two or more independent evidence types, such as a password plus a one-time code or hardware key. It reduces the impact of stolen passwords but does not remove the need for other controls.

The controls that create, protect, rotate, and terminate user sessions, including secure token generation, timeouts, and logout invalidation. Flaws here allow session hijacking and unauthorized reuse of authenticated state.

The use of mathematical techniques to protect data confidentiality, integrity, and authenticity. In applications it covers encryption in transit and at rest, hashing, key management, and correct use of vetted libraries.

The lifecycle processes for generating, storing, distributing, rotating, and destroying cryptographic keys. Poor key handling defeats strong algorithms, so keys are protected separately from the data they secure.

The controls that keep data confidential, accurate, and available according to its classification, including encryption, masking, retention limits, and access restrictions. Protection level is chosen based on data sensitivity and obligations.

The practice of recording security-relevant events and watching them for signs of attack or misuse. Logs must be protected from tampering and retained long enough to support investigation.

A platform that collects, correlates, and alerts on log and event data from many sources. It supports detection of application attacks and provides evidence during incident investigation.

The planned execution of reviews and tests, such as code review, dynamic testing, and penetration testing, to find weaknesses before attackers do. Results feed remediation and verification activities.

Analysis of source code or binaries without executing the application, looking for unsafe patterns and data flows. It finds issues early but often produces false positives that require triage.

Testing a running application from the outside by sending crafted requests and observing responses. It detects runtime issues such as misconfiguration and injection but has limited visibility into source code.

Authorized, goal-directed simulated attacks against an application to demonstrate exploitable weaknesses and their business impact. It is scoped, time-boxed, and followed by a remediation report.

The ongoing cycle of discovering, prioritizing, remediating, and verifying vulnerabilities across applications and dependencies. Prioritization considers severity, exploitability, exposure, and business context.

The controlled process of testing, deploying, and recording updates that fix defects in software and its dependencies. Delays in patching leave known vulnerabilities exploitable for longer.

The practice of identifying third-party and open-source components in an application and checking them against known vulnerability and license data. It produces an inventory that supports patching and due diligence.

The activity of confirming through evidence that implemented controls meet their specified requirements and acceptance criteria. Verification results are recorded and used to decide whether an application may proceed.

An event or series of events that actually or potentially harms the confidentiality, integrity, or availability of an application or its data. Incidents trigger the response process and may require notification.

A documented set of roles, steps, and communication paths for detecting, containing, eradicating, recovering from, and learning from security incidents. It is tested through exercises so it works under pressure.

The incident response step that limits the spread and impact of an incident, for example by isolating systems, revoking credentials, or blocking traffic. It balances stopping damage against preserving evidence.

The disciplined collection, preservation, and analysis of digital evidence so that findings are defensible and reliable. Evidence handling follows chain-of-custody practices and avoids altering original data.

A structured review after an incident that identifies root causes, evaluates the response, and assigns corrective actions with owners and dates. Its findings feed continual improvement and control updates.

The recurring cycle of measuring performance, identifying gaps, and changing processes or controls so application security effectiveness increases over time. It relies on evidence from monitoring, audits, and incidents.

A change made to remove the cause of a detected problem so it does not recur, tracked to completion with an owner and a due date. It differs from a quick fix that only addresses the symptom.

An independent, systematic examination of evidence to judge whether application security activities and controls conform to defined criteria. Findings are reported objectively and followed by corrective action.

A quantified measure used to judge how well application security objectives are being met, such as remediation time or test coverage. Good indicators are specific, repeatable, and tied to decisions.