Application Security Assessment: How to Calculate the Risk

An application security assessment is more than a box to check. It's the lens that reveals how exposed your applications really are. Calculating risk means moving beyond raw vulnerability counts to weigh severity, exploitability, business impact, and likelihood of attack.

The most pressing risks include broken access control, cryptographic failures, API security challenges, and emerging AI-driven attacks. Cybersecurity experts should approach this with precision: mapping every asset, modeling realistic threat scenarios, and applying contextual scoring so organizations know exactly which risks demand immediate action.

A step-by-step process to include scope definition, threat modeling, testing, and remediation, ensures both compliance and resilience.

What is an application security assessment?

Application security assessment is a structured process to evaluate how well an application resists threats. The evaluation aims to identify, validate, and help remediate security weaknesses that could be exploited to compromise confidentiality, integrity, or availability.

It examines architecture, code, data flows, configurations, and runtime environments to understand risk in context. Assessments often combine automated and manual testing, offering both technical findings and business impact analysis. Regular assessments are now table stakes: an annual minimum for most, and continuous monitoring for high-risk sectors.

What are the main risks in application security?

Modern applications face evolving risks. The OWASP Top 10 remains foundational, with broken access control, cryptographic failures, and injection attacks remaining at the top of the list. But new challenges are accelerating, such as the following:

Broken access control: Users can act beyond their authorized permissions, leading to data exposure or privilege escalation.

Risk: Unauthorized data access, privilege escalation, unauthorized actions, and potential data leakage or system compromise.

Cryptographic failures: Weak or improperly implemented encryption risks exposing sensitive data in transit or at rest.

Risk: Sensitive data exposure or theft, including personal, financial, or authentication data, due to weak or missing encryption.

Injection attacks: Unvalidated input allows attackers to execute malicious commands in databases or systems (e.g., SQL injection, Command Injection). By inserting malicious code into input fields, attackers can manipulate applications or databases.

Risk: Malicious code execution, data loss, unauthorized viewing or modification of data, and full system takeover via attacks like SQL, OS, or command injections.

Insecure design: Fundamental flaws in application design lead to unchecked security vulnerabilities.

Risk: Pervasive vulnerabilities throughout the application leading to exploitation, data breaches, and loss of business continuity due to fundamental flaws.

Security misconfiguration: Improper setup of servers, cloud services, or applications creates exploitable weaknesses.

Risk: Attackers can create entry points by default settings, open cloud storage, verbose error messages, or unpatched systems, allowing for unauthorized access or data leaks.

Vulnerable and outdated components: Using unpatched or obsolete libraries introduces known security flaws.

Risk: Exploitation through known vulnerabilities in third-party libraries or frameworks, potentially leading to data breach or compromise.

Identification and authentication failures: Weak authentication, poor login controls, and weak session management enable attackers to impersonate users or hijack sessions and accounts.

Risk: Account compromise, impersonation, unauthorized transactions, and loss of user trust due to weak password policies or session management.

Software and data integrity failures: Lack of sufficient protection allows for unauthorized modification of code or data.

Risk: Unauthorized code injection, tampering, or manipulation of application behavior, causing incorrect results or system compromise.

Insufficient logging and monitoring: Poor audit trails delay breach detection and response.

Risk: Delayed breach detection and response, allowing attackers to maintain persistent access and cause extended damage.

Server-Side Request Forgery (SSRF): Attackers trick servers into making unintended requests to internal systems, potentially compromising sensitive data.

Risk: Attackers tricking servers into requesting internal or external resources, potentially exposing sensitive information or enabling further attacks within internal networks.

API security gaps

These include shadow application programming interfaces (APIs), GraphQL-specific flaws, and the automated abuse of business logic.

Undocumented "shadow APIs" create security blind spots. GraphQL's flexible design introduces vulnerabilities like data exposure and DoS via nested queries. Automated attacks exploit API business logic, bypassing controls for unauthorized actions or data extraction without triggering typical defenses.

Associate risks:

• Shadow APIs expose sensitive data without proper security controls, creating invisible attack surfaces that lead to data breaches, compliance violations, and operational disruptions.
• GraphQL APIs can be exploited through excessive data exposure, injection vulnerabilities, and denial-of-service attacks caused by complex nested queries, which risk unauthorized access and service outages.
• Automated abuse of business logic allows attackers to manipulate API workflows, bypass controls, and perform unauthorized transactions undetected by traditional security measures.

AI-powered attacks

Examples include prompt injection, poisoned training data, and AI-generated phishing.

Prompt injection attacks exploit AI with malicious instructions to reveal data or execute unintended commands. Poisoned training data corrupts AI output by injecting harmful datasets. AI-generated phishing creates compelling, dynamic messages that bypass detection, thereby boosting the success of social engineering and credential compromise.

Associate risks:

• Prompt injection causes AI systems to execute unintended commands or reveal sensitive information by injecting malicious inputs.
• Poisoned training data corrupts model behavior and accuracy by introducing biased or malicious data during training, undermining AI reliability.
• AI-generated phishing produces highly convincing and targeted phishing campaigns with dynamic content that can easily bypass conventional defenses, increasing the risk of credential theft and fraud.

Cloud-native risks

Container escapes, Kubernetes misconfigurations, and serverless blind spots.

Attackers exploit container escapes via kernel flaws or weak configurations, gaining access to host systems. Kubernetes misconfigurations (e.g., permissive roles, exposed dashboards) allow extensive control. Serverless environments, despite abstracting infrastructure, create blind spots due to limited visibility and ephemeral nature, hindering threat detection.

Associate risks:

• Container escapes enable attackers to break out of isolated containers and access host systems, thereby compromising the overall integrity of the infrastructure.
• Kubernetes misconfigurations, such as overly permissive roles or exposed dashboards, provide attackers with broad access and control over cloud environments.
• Serverless architectures often lack comprehensive monitoring and logging, creating visibility blind spots that hinder detection of malicious activity and compromise response.

These risks don't just cause technical headaches. The average breach cost is nearly $4.5 million, with application-related incidents accounting for a quarter of all breaches.

How do we assess application security and compliance risk step by step?

A mature assessment follows a clear and systematic process, such as the following:

1. Define scope and map sensitive data. Inventory applications and trace data flows. This visibility helps identify where critical information resides, how it moves across systems, and where potential vulnerabilities may exist.

• Inventory: App(s), APIs, microservices, data stores, third-party services, SaaS integrations, environments (dev/test/prod).
• Business context: Identify critical transactions, users/roles, uptime requirements, and data sensitivity levels.
• Outline compliance obligations, such as ISO 27001, SOC 2, PCI DSS, HIPAA, GDPR/CCPA, and contracts/DPAs.

2. Map attack surfaces and trust boundaries. This includes APIs, endpoints, integrations, and user inputs. A thorough map ensures no entry point is overlooked, giving security teams a clear picture of where defenses are needed most.

• Data flows: Where sensitive data is created, processed, stored, transmitted, and deleted (including SaaS and AI tools).
• Trust boundaries: External users, partners, internal networks, cloud accounts/regions, tenant/namespace boundaries.
• Residency/retention: Required regions, legal holds, and their respective deletion timelines.

3. Threat modeling. Anticipate attack scenarios based on the types and motivations of malicious actors. This forward-looking approach helps prioritize defenses against the most likely and damaging threats.

• Identify assets and abuse cases: What could attackers or insiders try to do? (e.g., steal data, escalate privileges, exfiltrate via OAuth).
• Decompose the app: Break down entry points, components, third-party calls, and secrets.
• Rate threats by likelihood/impact; note assumptions and compensating controls.

4. Technical testing. Determine where the various types of testing scenarios are appropriate, whether Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), Interactive Application Security Testing (IAST), and Software Composition Analysis (SCA). These tools and methods expose vulnerabilities at every stage of the development lifecycle, from code to runtime.

• Automated scans: SAST, SCA, DAST, container/K8s/IaC scanners; secrets scanning.
• Manual testing: AuthZ and business logic, API fuzzing, Server-Side Request Forgery (SSRF), injection attacks, session flaws, and multi-tenant isolation checks.
• Configuration validation: Header/CSP checks, TLS tests, storage permissions, public exposure.
• Privacy checks: Data minimization, retention/deletion, DSAR readiness; redaction of sensitive logs.
• Disaster recovery/backup tests: Verify RTO (Recovery Time Objective)/RPO (Recovery Point Objective) to determine the frequency of data backups required and the speed at which critical services must be restored. Additionally, conduct restore tests and assess legal hold behavior in SaaS.

5. Validate findings: Separate real issues from noise. Filtering out false positives ensures teams focus on fixing genuine vulnerabilities without wasting time or resources.

6. Remediation strategy: Rank issues based on severity, exploitability, and business impact. Clear prioritization accelerates response, ensuring the most dangerous risks are addressed first.

• Quick wins: Config changes, header fixes, key/token rotations, permission right-sizing.
• Structural fixes: Authorization (AuthZ) refactors, data partitioning, tokenization, network segmentation, and policy-as-code guardrails.
• Exceptions: Time-bound risk acceptance with compensating controls and review cadence.

7. Deploy controls and monitoring: This involves access controls, encryption, and continuous monitoring. It also encompasses proactive defenses combined with real-time visibility, strengthening resilience against evolving attacks.

8. Report and document: Tailored reports for executives, compliance officers, and engineers. Customized reporting ensures decision-makers, regulators, and technical teams all get the insights they need in the right format.

• Executive summary: Top risks, trends, business impact.
• Technical report: Repro steps, evidence, code/config examples, references (OWASP ASVS/Top 10, NIST).
• Compliance mapping: Control status against ISO/SOC 2/PCI/HIPAA; evidence links.
• Audit package: Logs, screenshots, policies, change records, restore tests, and access reviews.

What should we include in an application security assessment?

Here's a concise, practical checklist of what to include in an application security assessment.

1. Scope and context

• Outline systems in scope: App, APIs, microservices, data stores, environments, third-party/SaaS dependencies.
• Business and compliance factors: Critical workflows, user roles, data sensitivity, RTO/RPO, applicable frameworks (ISO 27001, SOC 2, PCI, HIPAA, GDPR).

2. Architecture and design review

• AuthN/AuthZ: MFA, session lifecycle, token handling, object/action-level authorization, least privilege, SoD.
• Crypto/secrets: TLS 1.2/1.3, modern algorithms, key management (KMS/HSM), rotation, vault-backed secrets, short-lived creds.
• Multitenancy/isolation: Data partitioning, per-tenant keys, row/column/label security.
• Resilience/safety: Timeouts, retries, circuit breakers, rate limits, fail-safe defaults.

3. Data protection and privacy

• Data flows and mapping; classification; minimization.
• Retention/deletion, legal holds, DSAR readiness; logging redaction; IRM/DRM where needed.

4. Code and dependency security

• SAST and targeted manual code review of critical paths.
• Software Composition Analysis (SCA) for libraries/containers; Software Bill of Materials (SBOMs) to list all components and dependencies that comprise the software for transparency and supply chain risk management; signed artifacts; dependency update strategy.
• Secrets scanning across repos, images, and Infrastructure as Code (IaC).

5. Runtime and API testing

• DAST and API tests for IDOR/BOLA, injection, SSRF, XSS, CSRF, deserialization, mass assignment, schema validation, and rate limiting.
• Business logic abuse testing (fraud, replay, race conditions).
• Mobile/desktop specifics, if applicable.

6. Platform and configuration security

• Security headers (CSP, HSTS), strict cookies, CORS, and content validation.
• Cloud/IaC/K8s posture: storage policies, network exposure, secrets in configs, K8s RBAC/network policies/etcd encryption.
• CI/CD pipeline hardening (including continuous integration (CI), continuous delivery (CD), and deployment) to automatically build, test, and deploy code changes, protected branches, signed builds, and artifact repository security.

7. Logging, monitoring, and forensics

• Coverage for auth, admin actions, data access, and errors; retention and immutability; PII redaction.
• SIEM integration, tuned detections, alert runbooks, time sync.

8. Backup, recovery, and continuity

• Scope, immutability/WORM where needed; regular restore tests; documented RTO/RPO.

9. Third-party and supply chain

• SaaS/API integrations: scopes/permissions, token hygiene, least privilege, data-sharing restrictions.
• Vendor assurance (SOC 2/ISO, DPAs/BAAs, subprocessors, residency); open-source licensing; build pipeline security.

10. Risk analysis, reporting, and remediation

• Risk rubric (CVSS + business impact + data sensitivity + exploitability).
• Framework mapping (OWASP ASVS/API Top 10, NIST, ISO, PCI/HIPAA).
• Prioritized fixes with code/config examples, owners, SLAs; retest/verification plan.

11. Continuous assurance plan

• CI/CD gates for SAST/SCA/DAST and policy-as-code for IaC.
• Recurring assessments after material changes.
• Metrics: time-to-fix, % criticals closed on time, residual risk trend, automated control coverage.

What are the expected deliverables from an application security assessment?

A thorough assessment should produce actionable documentation that serves multiple stakeholders, from technical teams to executives and auditors:

Application security assessment deliverables

• Executive summary highlighting top risks and business impact
• Updated architecture and threat model diagrams
• Detailed findings with proof-of-concept evidence
• Prioritized remediation plan with SLAs and ownership
• Compliance mapping to relevant frameworks
• Retest report confirming vulnerability closure

What are the best practices for assessing application security?

The items listed below are field-tested best practices for assessing application security. Use this as a checklist and workflow you can operationalize.

Best practices for assessing application security

Expected deliverables include an executive summary and top risks, an updated architecture and threat model diagrams, with detailed findings with PoCs/evidence. Others include a remediation plan and SLAs, a retest report. Finally, comprehensive compliance mapping and audit-ready evidence.

1. Define scope and context up front

• You can't measure what you don't count. So, inventory the software infrastructure, including applications, APIs, microservices, data stores, environments (whether dev/test/stage/prod), third-party services, and SaaS dependencies.
• Capture business context by assessing critical workflows, user roles, data sensitivity, RTO/RPO, and compliance obligations (e.g., ISO 27001, SOC 2, PCI, HIPAA, GDPR).

2. Map data flows and trust boundaries

• Diagram where sensitive data is created, processed, stored, transmitted, and deleted.
• Note external integrations, identities, tenants/accounts, regions, and isolation boundaries (e.g., per-tenant keys).
• Identify residency, retention, and legal hold requirements.

3. Threat model early and iteratively

• Identify assets, their potential entry points, and abuse cases (including insider threats and supply chain vulnerabilities).
• Prioritize by likelihood and impact; then document assumptions and compensating controls.

4. Review the architecture and design framework

• With regards to authorization and authentication, focus on MFA, session hygiene, and object/action-level authorization. Also, review the granularity of least privilege and Separation of Duties (SOD).
• Ensure there's effective secrets management, with modern TLS, strong algorithms, KMS/HSM, rotation, vault-backed secrets, and short-lived tokens adopted.
• Multitenancy/isolation: Per-tenant keys/partitions; row/column/label security where applicable.
• Test the system's resilience by reviewing session timeouts, retries, circuit breakers, rate limits, and graceful degradation.

5. Secure code and dependencies

• SAST and secrets scanning in CI; break on criticals.
• SCA for libraries/containers; maintain SBOMs; signed artifacts and provenance checks.
• IaC/container/K8s scanning and baselines.

6. Test running apps like an attacker

Simulate various attacks and observe the system's response with DAST and API testing: IDOR/BOLA, injection, XSS/CSRF, SSRF, deserialization, mass assignment, schema validation, and rate limits.

• Apply business logic abuse testing with workflow bypasses, race conditions/replay attacks, and fraud detection.
• Mobile/Desktop specifics, if applicable.

7. Validate platform and configuration

• Security headers (CSP, HSTS), strict cookies, CORS, and content validation.
• Cloud/storage/network permissions, public exposure, secrets in configs; K8s RBAC/network policies/etcd encryption.
• Review the extent of CI/CD hardening, including protected branches, code review, and artifact registry security.

8. Logging, monitoring, and forensics

• Ensure coverage for authentication, administration, data access, and errors; retention and immutability; and PII redaction.
• Integrate with SIEM; tune detections; test alerting and IR playbooks.

9. Privacy and compliance checks

• Data minimization, consent, DSAR readiness, retention/deletion, legal holds.
• Map controls/findings to OWASP ASVS/API Top 10, NIST/ISO, PCI/HIPAA as applicable.

10. Risk rating, remediation, and retesting

• Use a rubric (CVSS + business impact + data sensitivity + exploitability).
• Provide prioritized fixes with code/config examples, owners, and SLAs.
• Retest to verify closure; track MTTR and % criticals closed on time.

11. Make the review continuous

• CI/CD gates for SAST/SCA/DAST; policy-as-code for IaC.
• Recurring manual assessments after material changes.
• Metrics: residual risk trend, coverage, time-to-fix, % automated controls.

Best practices mean making security part of the lifecycle

Run multi-layered testing: Combine and leverage a full suite of testing methods, such as SAST (for code-level vulnerabilities), DAST (for runtime flaws), IAST (for hybrid insights), and SCA (for open-source and dependency risks).

Validate findings: Distinguish real, exploitable issues from false positives to avoid wasting resources on noise.

Risk-based prioritization and remediation: Rank vulnerabilities by severity, exploitability, and business impact. Fix critical risks first and build a roadmap for medium/low risks to optimize effort. Also, fix based on business impact, not just CVSS scores.

Deploy Controls and continuous monitoring: Implement access controls, encryption, and security monitoring to prevent repeat exposures. Real-time visibility helps catch anomalies, policy drift, and credential misuse before they become incidents.

Report and document clearly: Tailor reporting for different audiences: high-level summaries for executives, compliance-focused evidence for auditors, and detailed technical findings for engineers.

Establish continuous review: Security isn't a one-off exercise. Regular assessments, combined with automated scanning and feedback loops, keep protection aligned with evolving threats.

What tools help with application security assessment?

No single tool is enough because effective application security assessments use a layered approach, combining SAST, DAST, IAST, and SCA with penetration testing, threat modeling, and continuous monitoring. Therefore, organizations rely on a mix of open-source and enterprise-grade tools, such as the following:

1. Static Application Security Testing (SAST)

These analyze codebases directly to spot insecure coding practices before apps are deployed.

• Scans source code or binaries before deployment.
• Detects vulnerabilities like insecure coding practices, hardcoded secrets, or injection flaws early in the development lifecycle.
• Examples: SonarQube, Checkmarx, Bearer, Fortify Static Code Analyzer, Veracode

2. Dynamic Application Security Testing (DAST)

They probe live applications for runtime vulnerabilities like SQL injection or XSS.

• Simulates real-world attacks on running applications.
• Helps uncover issues like authentication bypasses, misconfigurations, and runtime vulnerabilities.
• Examples: OWASP ZAP, Wapiti, Burp Suite, Acunetix, Netsparker

3. Interactive Application Security Testing (IAST)

Work inside running applications during functional testing to give contextual, real-time results.

• Combines SAST and DAST by monitoring applications in real time during testing.
• Provides deeper, contextual insights with fewer false positives.
• Examples: Contrast Security, Synopsys Seeker, Veracode IAST

4. Software Composition Analysis (SCA)

Scan open-source libraries and dependencies to flag known CVEs and license risks.

• Identifies vulnerabilities in open-source libraries and third-party dependencies.
• Essential for managing risks from reused code and ensuring license compliance.
• Examples: OWASP Dependency-Check, Snyk, Retire.js, Black Duck, WhiteSource (Mend), FOSSA

5. Penetration Testing Tools

Used by ethical hackers to simulate real-world attack scenarios and identify chained vulnerabilities.

• Ethical hacking frameworks (like Metasploit, Burp Suite, or OWASP ZAP) simulate advanced attacks.
• Useful for uncovering complex, chained vulnerabilities that automated scanners miss.
• Examples: Metasploit, Kali Linux, Burp Suite Pro, Core Impact

6. Threat Modeling Tools

Map out data flows and attacker paths to prioritize risks before writing code.

• Platforms like Microsoft Threat Modeling Tool or OWASP Threat Dragon map data flows and potential attack vectors.
• Help teams prioritize risks before coding begins.
• Examples: Microsoft Threat Modeling Tool, OWASP Threat Dragon, IriusRisk

7. Continuous Monitoring & SIEM Integration

Provide ongoing monitoring, anomaly detection, and compliance reporting.

• Tools like Splunk, ELK Stack, or similar integrations monitor application logs and traffic in real time.

These tools provide breadth of coverage, but orchestration and continuous oversight are needed. Each tool addresses a different layer of risk, but together, they create a complete security assessment ecosystem that spans from code to production.

How to assess third-party applications you don’t own?

The challenge with SaaS, AI tools, and third-party integrations is that traditional application security assessment tools were designed for applications you build and control. You cannot run SAST on a vendor's codebase or DAST against their production environment without permission and access. Instead, you must assess risk from the outside in, focusing on configurations, permissions, data flows, and behaviors.

The same principles of risk assessment apply, but the methods and tools must adapt to the reality that you are securing an ecosystem, not just an application.

Security teams need visibility into SaaS configurations, OAuth scopes, API integrations, data sharing patterns, and behavioral anomalies. They need to understand which identities (human and non-human) have access, what permissions they hold, and whether those permissions align with least privilege principles. They need to detect when sensitive data moves unexpectedly or when a third-party tool exhibits risky behavior.

Extending application security assessment practices to the SaaS and AI ecosystem means applying the same rigor to what you don't own as you do to what you build. It means continuous monitoring, behavioral analytics, and a unified view of risk across your entire digital environment.

From code review to ecosystem defense with Vorlon

Application security assessment is a structured, multi-layered process that reveals vulnerabilities, prioritizes risks, and guides remediation. By combining threat modeling, automated testing, manual validation, and continuous monitoring, organizations can move from reactive patching to proactive resilience.

Furthermore, as an industry we've invested significant time, tooling, and best practices frameworks around how to assess the risk of applications we build. But what about the applications we don't own, like SaaS, AI tools, and connected third-party service? Enterprises have moved massive amounts of sensitive data into these third-party systems, but visibility and control haven't kept up. Vorlon extends the rigor of application security assessment to the broader SaaS and AI supply chain by mapping data flows, monitoring integrations, and detecting behavioral anomalies.

Applying the same assessment discipline to both owned and third-party applications ensures comprehensive protection and resilience in an era where the boundaries of your application ecosystem are increasingly blurred.