COMP 6660 · Enterprise Cybersecurity Application Security

00 Introduction

Lessons 5.1 and 5.2 examined the platforms on which software runs — operating systems and endpoints. This lesson examines the software itself — the applications that deliver enterprise services and the practices through which secure software is built, tested, and deployed.

Applications are where enterprises deliver value. Web applications serve customers; APIs integrate partners and systems; mobile applications extend services to devices; internal applications run business processes. Each application is a distinct attack surface — a distinct set of vulnerabilities, a distinct set of interfaces, a distinct set of risks. An enterprise with hundreds of applications has hundreds of attack surfaces; an enterprise with thousands has thousands.

Application security is frequently the weakest link in enterprise security. Networks are segmented; operating systems are patched; endpoints are protected. But applications frequently contain vulnerabilities that no infrastructure control addresses — logic flaws, broken access control, injection flaws, insecure dependencies — that permit adversaries to bypass the surrounding controls. Many of the most consequential breaches have exploited application vulnerabilities rather than infrastructure weaknesses.

This lesson examines application security in detail. It establishes why application security matters. It examines the application attack surface — the interfaces, data, and dependencies through which applications can be attacked. It examines the OWASP Top 10 and the common application vulnerabilities that recur across applications. It examines secure development practices — the disciplines through which secure software is built. It examines application security testing — the methods through which vulnerabilities are identified. It examines dependency management — the discipline of managing the third-party components on which modern applications depend. It examines DevSecOps — the integration of security into development and operations. It examines runtime application protection and the specific considerations of APIs and microservices. And it closes with the pitfalls that recur across application security programmes.

The material here builds on the platform foundations from Lessons 5.1 and 5.2 and connects to the vulnerability management material from Lesson 3.3 and the supply-chain risk material from Lesson 3.7. It prepares for the database security material in Lesson 5.4 — applications and databases are closely coupled — and for the cloud and container security material in Lessons 5.5 and 5.6.

01 Learning objectives

By the end of this lesson you should be able to:

These objectives contribute to Unit 5 outcome U5.1 (secure infrastructure), and to Module 2 outcome M2.8. See the Unit 5 learning outcomes page for the full mapping.

02 Why application security matters

Applications are where enterprises deliver value and where users interact with enterprise systems. They are also where a substantial portion of enterprise breaches begin — because applications contain vulnerabilities that infrastructure controls do not address.

The consequence of application security failures

Application security failures appear across documented breaches:

• Injection flaws. SQL injection, command injection, and their variants have been exploited for decades — and remain common in applications. Injection permits the adversary to execute commands, extract data, or compromise the underlying system.
• Broken access control. Applications that grant access based on client-supplied data — direct object references — permit adversaries to access data and functionality they are not authorized to access. A recurring source of data exposure.
• Authentication flaws. Weak authentication, insecure session management, and credential storage weaknesses permit account compromise.
• Insecure dependencies. Vulnerabilities in third-party libraries — Log4Shell being the canonical example — permit compromise of applications that use them.
• Supply-chain compromise. Attacks on the build pipeline, on the software update mechanism, or on the dependencies themselves permit the adversary to insert malicious code into legitimate software (Lesson 3.7).

The pattern is consistent: application vulnerabilities permit adversaries to bypass infrastructure controls and access data or functionality that infrastructure controls cannot protect. Application security is essential — infrastructure security alone is insufficient.

03 The application attack surface

Applications present a broad attack surface — a large number of interfaces, components, and dependencies through which adversaries can attempt to compromise the application or the data and functionality it exposes.

Components of the application attack surface

Reducing the application attack surface

The foundational principle of application security is to reduce the attack surface to what the application requires:

• Minimise functionality. Applications should provide only the functionality they require — unnecessary features add attack surface.
• Minimise data. Applications should collect and store only the data they require — data minimisation reduces the consequence of compromise.
• Minimise dependencies. Applications should use only the dependencies they require — each dependency adds attack surface.
• Minimise exposure. Applications should expose only the interfaces they require — unnecessary endpoints, unnecessary parameters, unnecessary error messages add attack surface.
• Minimise privilege. Applications should run with the minimum privilege required — limiting what a compromise of the application achieves.

04 OWASP Top 10 and common application vulnerabilities

Application vulnerabilities fall into recognisable categories — categories that recur across applications, across languages, and across industries. The OWASP Top 10 — published by the Open Web Application Security Project — is the most widely recognised catalogue of these categories.

The OWASP Top 10

Why these categories recur

These categories recur because they share common causes:

• Trusting user input. Many vulnerabilities stem from applications that trust user input — using it without validation, passing it to interpreters, or using it to make security decisions.
• Missing security requirements. Applications are frequently developed without explicit security requirements — producing designs that lack the controls needed to protect the data and functionality they expose.
• Deferred security. Security is frequently deferred — through pressure to deliver, through assumptions that security can be added later, through insufficient security expertise on development teams.
• Complexity. Modern applications are complex — many components, many dependencies, many interactions. Complexity produces vulnerabilities.
• Human error. Applications are developed by people. People make mistakes. Some mistakes produce vulnerabilities.
• Reuse of insecure patterns. Developers frequently reuse patterns — from examples, from previous projects, from online resources — that contain vulnerabilities.

Beyond the OWASP Top 10

The OWASP Top 10 is a starting point, not a comprehensive catalogue. Several other categories of application vulnerability are also consequential:

• Business logic flaws. Vulnerabilities in the application's business logic — permitting adversaries to misuse the application in ways the designers did not anticipate. Not addressed by the OWASP Top 10; requires threat modelling and business context.
• Race conditions. Concurrent execution producing incorrect results — including security decisions that can be exploited through timing.
• Memory safety. Buffer overflows, use-after-free, and other memory safety issues — primarily in C and C++ applications.
• Client-side vulnerabilities. Cross-site scripting, cross-site request forgery, and other client-side attacks.
• API-specific vulnerabilities. Broken object level authorization, broken authentication on APIs, excessive data exposure, and others — reflected in the OWASP API Security Top 10.
• Mobile-specific vulnerabilities. Insecure data storage, insecure communication, and other mobile application vulnerabilities.

05 Secure development practices

Application security starts with how applications are developed. Secure development practices are the disciplines through which security is built into applications — rather than discovered in them after deployment.

Security requirements

Secure development begins with security requirements — explicit statements of what the application must do to protect the data and functionality it handles. Security requirements include:

• Authentication requirements. How users authenticate — password policy, multi-factor authentication, session management.
• Authorization requirements. How access is determined — roles, permissions, attributes, and how they are enforced.
• Data protection requirements. What data is collected, how it is protected in transit and at rest, how it is retained, and how it is disposed of.
• Input validation requirements. What input the application accepts, how it is validated, and how invalid input is handled.
• Error handling and logging requirements. How errors are handled, what is logged, and how logs are protected.
• Regulatory and compliance requirements. What obligations apply to the application — privacy, sectoral regulation, contractual requirements.

Threat modelling for applications

Threat modelling — examined in detail in Lesson 3.2 — is a critical application security practice. Applied to applications, threat modelling:

• Identifies threats specific to the application's design, data flows, and trust boundaries.
• Informs security requirements — the threats identified drive the controls the application requires.
• Prioritises security effort — the threats assessed as highest risk receive the most attention.
• Surfaces design flaws — security issues that are best addressed at the design stage, before code is written.
• Documents the security posture — the threat model becomes part of the application's documentation, supporting review and improvement.

Secure coding practices

Secure coding practices are the specific techniques through which developers avoid introducing vulnerabilities:

Secure development frameworks

Several frameworks support secure development:

• OWASP ASVS (Application Security Verification Standard). A comprehensive framework of application security requirements — used to define security requirements, to assess applications, and to guide development.
• OWASP SAMM (Software Assurance Maturity Model). A framework for assessing and improving an organisation's software security practices — providing a roadmap for maturity improvement.
• NIST SSDF (Secure Software Development Framework). NIST's framework for secure software development — providing a set of practices that organisations should adopt.
• Microsoft SDL (Security Development Lifecycle). Microsoft's framework for secure development — widely adapted and used across the industry.
• BSIMM (Building Security In Maturity Model). A descriptive model of software security practices — based on observation of what organisations actually do.

06 Application security testing

Application security testing is the set of practices through which application vulnerabilities are identified — before deployment where possible, and throughout the application's lifecycle. Different testing approaches identify different types of vulnerabilities; effective programmes combine multiple approaches.

Application security testing approaches

Integrating testing into development

Application security testing is most effective when integrated into the development lifecycle — rather than performed as a separate activity after development:

• Testing during development. SAST and SCA run automatically as developers commit code — identifying vulnerabilities early, before they progress.
• Testing in CI/CD. Security testing integrated into continuous integration and continuous delivery pipelines — every build is tested; vulnerabilities are identified before deployment.
• Testing before release. DAST and penetration testing before release — testing the deployed application in a pre-production environment.
• Testing in production. Continuous testing of the deployed application — through bug bounty, through continuous scanning, through production monitoring.
• Testing after change. Testing whenever the application changes — new features, new dependencies, configuration changes.

Prioritising application security findings

Application security testing produces findings — sometimes many findings. Prioritisation is essential — applying the risk-based prioritisation principles from Lesson 3.3 to application findings:

• Exploitability. Vulnerabilities that can be easily exploited — with public exploits, without authentication, without user interaction — warrant higher priority.
• Exposure. Vulnerabilities on internet-facing applications warrant higher priority than vulnerabilities on internal applications.
• Impact. Vulnerabilities that permit access to sensitive data, administrative functionality, or critical systems warrant higher priority.
• Confidence. Vulnerabilities confirmed as real warrant higher priority than potential vulnerabilities with high false-positive probability.
• Age. Vulnerabilities that have been outstanding for extended periods warrant escalation.

07 Dependency management

Modern applications are assembled from dependencies — open-source libraries, commercial components, frameworks, and cloud services. Each dependency is a potential source of vulnerability, and each introduces supply-chain risk. Dependency management is the discipline of managing these dependencies — knowing what the application uses, keeping track of vulnerabilities, and updating dependencies promptly.

Why dependency management matters

• Dependencies are numerous. Modern applications use dozens, hundreds, or thousands of dependencies — direct and transitive — frequently without full visibility into what is used.
• Dependencies have vulnerabilities. Open-source dependencies are subject to the same vulnerability discovery process as any other software. Vulnerabilities in dependencies are inherited by applications that use them.
• Dependencies are frequently outdated. Applications accumulate dependencies over time; dependencies are updated irregularly; outdated dependencies accumulate known vulnerabilities.
• Dependencies are a supply-chain target. Adversaries target dependencies — through malicious packages, through compromised maintainer accounts, through typosquatting, through dependency confusion (Lesson 3.7).

Notable dependency vulnerabilities

Dependency management practices

Supply-chain risk management

Dependency management is one component of supply-chain risk management — the broader discipline examined in Lesson 3.7. Supply-chain risk management for software includes:

• Third-party supplier assessment. Assessing the security practices of commercial software suppliers.
• Open-source project evaluation. Assessing the health and security of open-source projects the application depends on.
• Build pipeline security. Protecting the systems through which the application is built — reducing the risk of build- pipeline compromise.
• Code signing and provenance. Signing built artifacts and verifying provenance — supporting detection of tampered software.
• SBOM sharing and consumption. Producing SBOMs for the enterprise's own software and consuming SBOMs from suppliers.
• Continuous monitoring. Monitoring dependencies and suppliers for security issues — vulnerability disclosures, breach notifications, maintainer changes.

08 DevSecOps

DevSecOps is the integration of security into development and operations — embedding security throughout the software delivery lifecycle rather than adding it at the end. It is a substantial evolution from traditional development practices — where security was a separate phase, often an obstacle to delivery — toward a model where security is a shared responsibility integrated into every phase.

Why DevSecOps matters

• Development velocity has increased. Agile development, continuous deployment, and rapid iteration have compressed development timelines — leaving less room for traditional security reviews.
• Traditional security is a bottleneck. Security reviews at the end of development delay deployment — producing pressure to bypass security, or to treat it as a compliance exercise.
• Security in development is more effective. Security issues identified early are cheaper to fix, less risky to fix, and less likely to be introduced than issues discovered later.
• Security in development is more scalable. Automated security testing integrated into CI/CD scales to the volume of development; manual security reviews do not.
• Security requires developer engagement. Developers understand the application; security teams understand security. Effective security requires the two working together — which DevSecOps enables.

DevSecOps practices

DevSecOps challenges

• Cultural change. DevSecOps requires a cultural shift — security is no longer a gate, but a shared responsibility. Cultural change is difficult.
• Skills. DevSecOps requires developers to understand security and security teams to understand development. Both are challenging to develop.
• Tool integration. Security testing tools must integrate with development tooling — producing integration work and operational complexity.
• False positives. Automated security testing produces false positives — slowing development and eroding trust in the testing.
• Coverage. Automated testing does not catch every vulnerability — particularly logic flaws and business logic issues. Combining automated testing with manual review and penetration testing is essential.
• Legacy applications. DevSecOps applies to new development; legacy applications without modern tooling frequently cannot benefit from the same approaches.

09 Runtime application protection

Secure development and testing reduce the likelihood of vulnerabilities reaching production — but they do not eliminate them. Runtime application protection provides a defence layer at the application itself — detecting and blocking attacks that secure development and testing did not prevent.

Web Application Firewalls (WAFs)

A Web Application Firewall (WAF) is a protection layer deployed in front of web applications — inspecting HTTP/HTTPS traffic and blocking requests that match attack patterns.

• Signature-based detection. WAFs detect attacks based on signatures — patterns that characterise common attacks (SQL injection, XSS, path traversal, and others).
• Behavioural detection. Modern WAFs supplement signatures with behavioural analysis — detecting attacks based on unusual behaviour rather than on known patterns.
• Virtual patching. WAFs can provide "virtual patching" — blocking exploitation of a vulnerability before the underlying code is patched. Useful for vulnerabilities that cannot be patched immediately.
• Deployment models. WAFs can be deployed as appliances, as cloud services, as software in the application path, or as agents on the application server.
• Limitations. WAFs produce false positives; they cannot detect logic flaws; they can be bypassed by sophisticated attackers; they do not replace secure development.

Runtime Application Self-Protection (RASP)

RASP (Runtime Application Self-Protection) is an application-level protection mechanism — integrated into the application (or its runtime) — that detects and blocks attacks in real time from within the application.

• In-application detection. RASP runs inside the application — with visibility into the application's execution, data, and context — and can detect attacks with more context than external tools.
• Real-time response. RASP can block attacks in real time — preventing exploitation of vulnerabilities the application contains.
• Deployment considerations. RASP requires integration with the application or its runtime — through instrumentation, through libraries, or through platform support.
• Limitations. RASP can affect application performance; integration is not always feasible; coverage depends on the platforms supported.

API gateways and protection

For API-based applications, API gateways provide runtime protection — authenticating callers, enforcing rate limits, validating input, and blocking malicious requests. API gateways are examined further in Section 9.

Runtime protection in context

Runtime protection is a defence-in-depth layer — supplementing, not replacing, secure development and testing. Its value is:

• Protecting unpatched vulnerabilities. When a vulnerability cannot be patched immediately, runtime protection can mitigate exploitation.
• Detecting attacks in production. Runtime protection provides visibility into attacks against production applications — informing response and improvement.
• Protecting legacy applications. Applications that cannot be updated can be protected by runtime controls.
• Reducing exploitation window. Runtime protection reduces the window between vulnerability disclosure and exploitation — providing protection while patches are developed and deployed.

10 APIs and microservices

Modern applications increasingly expose APIs — programming interfaces through which other applications integrate — and are increasingly built from microservices — small, independently deployable services that communicate through APIs. APIs and microservices introduce specific security considerations.

API security considerations

The OWASP API Security Top 10

OWASP publishes a specific Top 10 for API security — reflecting the specific vulnerabilities that apply to APIs:

• Broken Object Level Authorization (BOLA). APIs that permit access to objects based on client-supplied identifiers without verifying the caller's authorization.
• Broken Authentication. Weak authentication on APIs — permitting credential attacks, token compromise, or authentication bypass.
• Broken Object Property Level Authorization. APIs that permit access to properties the caller is not authorized to access.
• Unrestricted Resource Consumption. APIs without rate limits or resource constraints — permitting abuse and denial of service.
• Broken Function Level Authorization. APIs that permit access to functions the caller is not authorized to use.
• Unrestricted Access to Sensitive Business Flows. APIs that permit abuse of business flows — bulk operations, sensitive transactions.
• Server-Side Request Forgery. APIs that fetch remote resources based on user-supplied URLs without validation.
• Security Misconfiguration. API misconfiguration — insecure defaults, exposed documentation, unnecessary features.
• Improper Inventory Management. Unknown APIs, outdated API versions, shadow APIs.
• Unsafe Consumption of APIs. Applications that use third-party APIs without validating the data they receive.

Microservices security

Microservices architectures — applications built from small, independently deployable services — introduce specific security considerations:

• Service-to-service authentication. Services must authenticate to each other — mutual TLS, service identity, or equivalent.
• Service-to-service authorization. Services must determine what other services are permitted to do — policy enforcement at the service level.
• Service mesh. A service mesh provides identity, authentication, authorization, and observability for microservices — centralising the controls that would otherwise be implemented in each service.
• Workload identity. Each service has a distinct identity and access policy — no service is trusted by virtue of its position (Lesson 4.5).
• API gateway. An API gateway provides centralised authentication, authorization, rate limiting, and monitoring for services — a single control point for API security.
• Observability. Microservices produce substantial telemetry — logs, metrics, traces — that supports detection and investigation.

11 Common pitfalls

Enterprise application security programmes fail in predictable ways. Recognising the pitfalls accelerates improvement.

Pitfall 1 — Security deferred to the end of development

Security testing performed at the end of development — producing findings that are expensive to fix, or bypassed under schedule pressure.

Mitigation: Integrate security into the development lifecycle. Shift left — apply security practices from design through delivery.

Pitfall 2 — No threat modelling

Applications designed without threat modelling — producing designs that lack the controls needed to protect their data and functionality.

Mitigation: Conduct threat modelling for applications — particularly those handling sensitive data or exposed to the internet.

Pitfall 3 — Insufficient security testing

Applications tested for functionality but not for security — vulnerabilities discovered in production, through incidents, or through external reports.

Mitigation: Implement comprehensive security testing — SAST, DAST, SCA, penetration testing — integrated into the development lifecycle.

Pitfall 4 — Dependency blind spots

Applications using dependencies without visibility into what they use — unable to assess exposure when vulnerabilities are disclosed.

Mitigation: Implement software composition analysis (SCA). Generate and maintain SBOMs. Monitor dependencies for vulnerabilities.

Pitfall 5 — Outdated dependencies

Applications accumulating outdated dependencies with known vulnerabilities — because updates are deferred or not performed.

Mitigation: Update dependencies regularly. Automate dependency updates where feasible. Prioritise updates addressing vulnerabilities.

Pitfall 6 — Broken access control in applications

Applications that enforce access control improperly — permitting access based on client-supplied data, missing authorization checks, or enforcing authorization at the wrong layer.

Mitigation: Enforce access control on the server. Verify authorization on every request. Test access control thoroughly.

Pitfall 7 — Insufficient API inventory and protection

Enterprises that do not know what APIs they expose — leaving APIs unmanaged, unprotected, and vulnerable to API-specific attacks.

Mitigation: Inventory APIs. Implement API gateways for authentication, authorization, and monitoring. Address the OWASP API Security Top 10.

Pitfall 8 — DevSecOps without culture

DevSecOps practices implemented as a tooling exercise — without the cultural change that makes them effective. Security remains a gate rather than a shared responsibility.

Mitigation: Address culture alongside tooling. Embed security teams in development. Foster shared responsibility. Invest in developer security education.

Pitfall 9 — Alert fatigue from security testing

Security testing producing excessive findings — many false positives — eroding trust and producing alert fatigue. Developers ignore security testing results.

Mitigation: Tune security testing tools. Prioritise findings. Focus on what matters. Integrate remediation into development workflows.

Pitfall 10 — No security monitoring in production

Applications monitored for functionality but not for security — vulnerabilities exploited in production without detection.

Mitigation: Monitor applications for security events — authentication anomalies, unusual access, injection attempts, and other attack indicators. Integrate with the SOC.

12 Key concepts

The terms below are used throughout Unit 5. Capture them in your own words as you work through the lesson.

Application security

The discipline of protecting applications — the software that delivers enterprise services — from vulnerabilities and attacks. Includes secure development, testing, dependency management, and runtime protection.

Application attack surface

The interfaces, components, and dependencies through which applications can be attacked — user input, authentication, authorization, session management, business logic, APIs, dependencies, and configuration.

OWASP Top 10

The most widely recognised catalogue of application vulnerability categories — broken access control, cryptographic failures, injection, insecure design, security misconfiguration, vulnerable components, authentication failures, integrity failures, logging failures, and SSRF.

Injection

A class of vulnerabilities in which untrusted data is interpreted as code or commands by the application or its dependencies — SQL injection, command injection, LDAP injection, and others.

Broken access control

Failures in access control — permitting users to access data or functionality they are not authorized to access. Includes direct object references and missing authorization checks. Frequently the most consequential application vulnerability category.

Direct object reference

An application pattern in which access to a resource is granted based on a client-supplied identifier without verifying the subject's authorization. A common source of data exposure.

Secure development

The disciplines through which security is built into applications — security requirements, threat modelling, secure coding, and security testing.

Security requirements

Explicit statements of what the application must do to protect the data and functionality it handles — authentication, authorization, data protection, input validation, error handling, logging.

Threat modelling

The structured process of identifying and analysing threats that could affect an application. Examined in detail in Lesson 3.2.

Secure coding practices

The specific techniques through which developers avoid introducing vulnerabilities — input validation, output encoding, parameterised queries, established libraries, secure session management, and others.

OWASP ASVS

Application Security Verification Standard — a comprehensive framework of application security requirements, used to define requirements and assess applications.

OWASP SAMM

Software Assurance Maturity Model — a framework for assessing and improving an organisation's software security practices.

NIST SSDF

Secure Software Development Framework — NIST's framework of practices for secure software development.

SAST (Static Application Security Testing)

Testing that analyses source code for vulnerabilities without executing the application.

DAST (Dynamic Application Security Testing)

Testing that examines the running application for vulnerabilities — through automated scanning and manual testing.

IAST (Interactive Application Security Testing)

Testing that combines SAST and DAST — analysing the application from within during runtime testing.

SCA (Software Composition Analysis)

Analysis of applications and their dependencies to identify vulnerable components. Essential where third-party libraries are used at scale.

SBOM (Software Bill of Materials)

A machine-readable inventory of the components that make up a software artifact. Examined in Lesson 3.7.

Dependency management

The discipline of managing the dependencies an application uses — knowing what is used, monitoring for vulnerabilities, and updating promptly.

DevSecOps

The integration of security into development and operations — embedding security throughout the software delivery lifecycle.

Shift left

Applying security practices earlier in the development lifecycle — design, requirements, coding.

Shift right

Applying security practices in production — through runtime protection, monitoring, and continuous testing.

WAF (Web Application Firewall)

A protection layer in front of web applications — inspecting HTTP/HTTPS traffic and blocking requests that match attack patterns.

RASP (Runtime Application Self-Protection)

An application-level protection mechanism — integrated into the application or its runtime — that detects and blocks attacks in real time from within the application.

API (Application Programming Interface)

A programming interface through which applications integrate with other systems. APIs are a distinct attack surface with specific security considerations.

BOLA (Broken Object Level Authorization)

The failure to verify that the caller is authorized to access the specific object they are requesting. Frequently the most consequential API vulnerability.

Service mesh

A container and microservices control that provides identity, authentication, authorization, and observability for microservices.

API gateway

A control point for API security — providing centralised authentication, authorization, rate limiting, and monitoring for APIs.

13 Activities

The activities below help you test your understanding and prepare for the unit discussion and Assignment 2. They are not graded, but completing them will substantially improve your preparation.

14 Self-check

Answer the questions below before moving to Lesson 5.4. If you cannot answer a question confidently, revisit the corresponding section.

15 Summary

This lesson has examined application security — the discipline of protecting the software that delivers enterprise services. The essential points are:

• Application security matters because applications contain vulnerabilities that infrastructure controls cannot address. They expose enterprise data and functionality, are frequently internet-facing, and depend on third parties.
• The application attack surface is broad. User input, authentication, authorization, session management, business logic, data storage, APIs, dependencies, configuration, infrastructure integration, error handling, and administrative interfaces.
• The OWASP Top 10 catalogues the common application vulnerabilities. Broken access control, cryptographic failures, injection, insecure design, security misconfiguration, vulnerable components, authentication failures, integrity failures, logging failures, and SSRF.
• Secure development practices build security in from the start. Security requirements, threat modelling, secure coding practices, and secure development frameworks (OWASP ASVS, SAMM, NIST SSDF).
• Application security testing identifies vulnerabilities. SAST, DAST, IAST, SCA, penetration testing, and bug bounty — each with strengths and uses, integrated into the development lifecycle.
• Dependency management addresses the third-party components on which applications depend. Visibility, vulnerability monitoring, provenance, integrity, and update management — with SBOM and SCA as the enabling tools.
• DevSecOps integrates security into development and operations. Security as code, security in CI/CD, shift left and shift right, collaboration, culture, and automation.
• Runtime application protection provides a defence-in-depth layer. WAFs, RASP, and API gateways — supplementing, not replacing, secure development.
• APIs and microservices introduce specific security considerations. API authentication, authorization, data exposure, rate limiting, and inventory — with the OWASP API Security Top 10 as the reference. BOLA is frequently the most consequential API vulnerability.
• Common pitfalls recur. Security deferred to the end; no threat modelling; insufficient security testing; dependency blind spots; outdated dependencies; broken access control; insufficient API inventory; DevSecOps without culture; alert fatigue; no production monitoring.

These ideas prepare for Lesson 5.4, which examines database security — the discipline of protecting the data stores on which applications depend and that hold the enterprise's most sensitive information.