Revisione della sicurezza applicativa: ambito, metodi e frequenza

An application security review is a structured examination of how an application is designed, built and operated, carried out to find weaknesses before an attacker or an incident does. It combines architecture analysis, threat modelling, manual code review and dynamic testing, and it ends in prioritised findings with proposed fixes rather than a pass or fail stamp. This article explains what such a review covers, how it differs from a penetration test or an audit, how it is performed, when it should be repeated and what to demand from a development supplier.

Vicedomini Softworks

Build Security Into Your Software

Vicedomini Softworks builds custom software with Zero Trust security, targeted testing, production monitoring and ongoing application maintenance.

Ask for a consultation

TL;DR

A review assesses design, code, dependencies, data handling and operations together, and each finding carries an impact assessment and a proposed mitigation.
It differs from a penetration test, which validates whether a specific attack succeeds, and from an audit, which measures conformity to defined criteria.
Methods are chosen according to the application’s risk profile, and automated checks in the CI/CD pipeline support the manual work.
A review is not a one-time certificate: it should recur as requirements, architecture and releases change.
The acquiring organisation must evaluate the software against its own security requirements, whoever built it.

What an application security review is
Review, penetration test and audit compared
What the review should cover
How a review is carried out
When to review, and how often
Acting on findings and holding suppliers to account
Standards that give the review a frame
Our perspective
How we can help
FAQ
Sources

What an application security review is

OWASP describes an application security test as a method of evaluating the effectiveness of application security controls through active analysis for weaknesses, technical flaws and vulnerabilities, with the findings presented together with an impact assessment and a proposed mitigation or technical solution (OWASP Web Security Testing Guide). A review applies that discipline to the whole application as an engineered system, not only to its exposed surface.

The vocabulary matters because it fixes what the reviewer is looking for. The same OWASP guide defines a vulnerability as a weakness in an application’s design, implementation, operation or management that could compromise security objectives, and a threat as an actor or event that may harm application assets by exploiting such a weakness. A review therefore never reports weaknesses in isolation: it relates each one to the actors able to exploit it and to the business consequence if they do.

That relationship explains why the same software can carry very different risk in different organisations. OWASP’s Top 10 for 2025 explains that application risk depends on threat agents, attack vectors, exploitability, missing controls, technical impact and business impact (OWASP Top 10:2025). An internal tool with no external exposure and a public payment API may share a codebase pattern and still deserve entirely different priorities.

The risks a review is meant to surface

The OWASP testing framework gives a representative list of what a review looks for: broken authentication and authorisation, insecure session or token handling, inadequate input validation, unsafe cryptography, failures of data confidentiality and privacy, insecure APIs and integrations, cloud or container misconfiguration, exposed secrets, vulnerable dependencies, supply-chain weaknesses, and insufficient monitoring or incident-response controls (OWASP Testing Framework).

One practical objective sits behind the list. A review aims to surface design and implementation risks early in the software development lifecycle, when they cost less to resolve and before they turn into operational exposure (Cyfenders). Finding a flawed trust boundary in a design document is a conversation; finding it in production is an incident.

Review, penetration test and audit compared

The three terms are used loosely in procurement documents, and the confusion leads buyers to commission the wrong exercise. The distinctions below follow the definitions published by industry bodies.

Exercise	Core question	Typical method	Output
Application security review	Is the application designed and built with security considered appropriately?	Architecture analysis, threat modelling, manual code review, dynamic testing	Prioritised findings with impact and mitigation
Penetration test	Can a specific system withstand a specific attack?	Manual exploitation of weaknesses	Demonstrated exploit paths and their impact
Vulnerability assessment	Which known weaknesses are present?	Largely automated scanning	List of identified vulnerabilities
Security audit	Does the system conform to established criteria?	Systematic evaluation against a standard or policy	Conformity statement and gaps

TechTarget summarises the audit as a systematic evaluation of conformity to established criteria, whereas a penetration test checks whether a specific system can withstand a specific attack (TechTarget). CREST draws the further line between vulnerability assessment, which primarily identifies vulnerabilities and is largely automated, and penetration testing, which uses manual techniques to exploit weaknesses and understand their impact (CREST).

A review sits upstream of both. Unlike penetration testing, which focuses on exploit validation, it examines the structural and design decisions of an application to provide assurance that security has been considered appropriately (Cyfenders). In practice the exercises complement each other: the review finds the design flaws a scanner cannot see, and a penetration test confirms which of the remaining weaknesses are genuinely exploitable.

What the review should cover

A comprehensive review follows the application from its design to its operation. OWASP’s Secure-by-Design Framework, still a draft at version 0.5 from August 2025, lists the design-level topics: core secure design principles, service architecture and trust boundaries, data classification and protection, reliability and fault tolerance, access control, and design-time provisions for monitoring and incident response (OWASP Secure-by-Design Framework).

Design and architecture

This layer examines data flows and trust boundaries: where untrusted input enters, which services trust which, where sensitive data is stored and how it moves between components. Authentication and authorisation models are checked here, because a flaw in how identities and permissions are propagated between services cannot be repaired by patching a single function. Configuration choices that belong to the architecture, such as how a SaaS platform authenticates outbound email, also fall in scope; for a multi-tenant product, rolling out DMARC safely for SaaS is one example of a design decision that protects customers from spoofed messages sent in the platform’s name.

Application data flows across trust boundaries

Code, dependencies and secrets

OWASP’s secure code review guidance describes manual examination of source code to identify vulnerabilities that automated tools may miss, including defects in application logic, data flow and implementation details (OWASP Secure Code Review Cheat Sheet). Business-logic flaws are the typical example: a discount endpoint that accepts negative quantities passes every scanner, yet it is plainly a defect for anyone who reads the code with the business rules in mind.

Alongside the manual work, the review inventories third-party libraries and looks for committed credentials. Fortinet’s assessment service, for instance, bundles static analysis, software composition analysis for third-party libraries, infrastructure-as-code scanning, secret scanning and dynamic testing (Fortinet), which shows how far a modern review extends beyond the application’s own source.

Runtime, configuration and operations

The OWASP framework also includes configuration review, so the deployed environment is examined with the code: container and cloud settings, network exposure, logging, alerting and the incident-response path. An application that is secure on paper but produces no usable audit trail leaves the organisation blind at precisely the moment it needs evidence.

How a review is carried out

The method is a combination of threat modelling, manual code review and dynamic testing, and the proportions depend on the application’s risk profile. Automated tools are often integrated into the development pipeline to support continuous assurance (OWASP Testing Framework). GitLab’s published process describes the same trio, applied to applications that are either deployed or still in development (GitLab Handbook).

Three complementary application security review methods

A sound engagement usually moves through four stages, described here in narrative form because the order carries the logic. Scoping comes first: the reviewer establishes what the application does, which data it holds, who can reach it and which regulations apply, because these answers determine the depth of every later stage. Threat modelling follows, mapping plausible attackers and abuse paths against the architecture so that effort goes where impact is greatest. The evidence-gathering stage then combines manual code reading with tool-assisted analysis and dynamic testing against a staging environment. Finally, the reviewer reports findings ranked by exploitability and business impact, each with a concrete remediation.

Automation inside the pipeline

OWASP recommends that CI/CD pipelines carry automated security checks at several stages, such as static analysis and dependency scanning at build time and dynamic testing during staging (OWASP Testing Framework). These checks catch regressions between human reviews, but they do not replace them: they answer the questions a tool can formulate, not the ones a reviewer raises after reading how the system actually behaves.

Mobile applications

For mobile software, NIST’s app-vetting guidance says an evaluation determines whether an application conforms to the organisation’s security requirements; testing by tools and by humans produces vulnerability reports and risk assessments, which support a decision to approve or reject the app (NIST SP 800-163 Rev. 1). The same document stresses that an app having passed an official store’s checks does not by itself show conformance with the organisation’s own requirements.

When to review, and how often

Security belongs in every phase of development. OWASP advises adding one or more security activities to each phase of the software development lifecycle for new software (OWASP Application Security Program), and observes that doing so leaves fewer vulnerabilities to fix later (OWASP Security Culture).

The natural trigger points are a new product before launch, a significant architectural change, the integration of a new third-party system, a migration to new infrastructure, an acquisition of software built elsewhere, and the aftermath of an incident. For existing systems with long histories, a review is also the first step of a modernisation plan, because it separates debt that is merely untidy from debt that is exploitable.

Repetition is the other half of the answer. GitLab’s handbook states that reviews are not one-and-done and can continue as the application evolves, and that they should evolve with the application rather than serve as a one-time certification (GitLab Handbook). NIST notes that re-vetting protocols are critical and that applications may need re-evaluation periodically, for instance quarterly or annually, depending on risk tolerance and the frequency of updates (NIST SP 800-163 Rev. 1). A product released weekly with sensitive data warrants a tighter cycle than a stable internal tool.

Acting on findings and holding suppliers to account

A report has value only when its findings are fixed. NIST’s Secure Software Development Framework advises working with developers to decide what to fix from bug reports and ensuring that managers allocate time for remediation (NIST SP 800-218). Prioritisation should follow the risk factors outlined earlier: a medium-severity flaw in an internet-facing authentication flow can outrank a high-severity one in an isolated batch job. Every fixed finding should be retested, and the retest recorded.

When software is bought or outsourced, the same framework gives acquirers a common vocabulary to state secure development requirements to suppliers. Contracts can then ask concrete questions: which review activities occur in each phase, how dependencies are tracked, how secrets are managed, how incidents are reported and whether the customer may commission independent testing. The ESET guide on vetting apps raises similar questions for buyers, including whether penetration testing is permitted and what the vendor’s incident-response plan is (ESET Digital Security Guide).

Standards that give the review a frame

A review is easier to defend when it maps to recognised references. ISO/IEC 27034-1 provides a standardised framework for integrating security into the processes used to manage in-house, acquired and outsourced applications; the standard was confirmed in 2022 (ISO/IEC 27034-1). Its part 7 covers requirements for replacing specified application security control activities with a rationale that defines an expected level of trust (ISO/IEC 27034-7).

On the practical side, OWASP recommends the Application Security Verification Standard as a comprehensive, verifiable standard for application design, coding, testing and architecture, and urges integrating secure design reviews, threat modelling, secure code reviews and penetration testing into existing processes to maintain an acceptable security posture (OWASP Application Security Program). Using the ASVS levels as acceptance criteria gives both parties an objective definition of done.

Our perspective

We approach a security review as an engineering activity first and a reporting activity second. The most consequential weaknesses we encounter in enterprise Java, Spring Boot, Quarkus, Next.js and cloud-native estates are rarely exotic: they are inconsistent authorisation between services, integrations that trust each other more than they should, and observability that was never designed to answer a security question.

Because clients work directly with the engineers who design, build and maintain their software, the person who reads the code is also the person who explains the consequence and the remedy. There is no account-manager layer to dilute a finding between the review and the decision. We have no vendor bias, so recommendations are written down and justified on the client’s architecture instead of a product preference, and we limit simultaneous projects so that a review receives the attention of someone who can read an entire system.

Our advice to organisations is to treat a review as the start of a loop: review, remediate, retest, then fold the checks that proved valuable into the delivery pipeline so that the next review begins from a higher baseline.

— Pepe F.

How we can help

Our code audit and technical debt service examines an existing application for security and maintainability weaknesses, and our technical consulting turns the findings into a written roadmap. For organisations that want continuing senior oversight, the CTO Advisory plan starts from €1,800 per month, Fractional CTO from €4,000 per month and CTO Partner from €7,500 per month, while an initial assessment starts from €3,500 as a one-off engagement. Details of each are on our CTO subscription page, and the full scope of delivery is described under our services.

Vicedomini Softworks

For a first conversation about an application you own or plan to acquire, the custom software consulting page explains how an engagement begins.

FAQ

Is an application security review the same as a penetration test?

No. A penetration test checks whether a specific system can withstand a specific attack, using manual exploitation to show real impact. A review examines the design and implementation choices behind the application, so it finds structural flaws that an attack simulation may never reach.

How often should an application be reviewed?

There is no single interval. NIST suggests periodic re-evaluation, for instance quarterly or annually, depending on risk tolerance and how often the application is updated. Major architectural changes and new integrations justify an additional review outside the regular cycle.

What does a review produce?

It produces findings that each include an impact assessment and a proposed mitigation or technical solution. Good reports rank findings by exploitability and business impact, so the development team can decide what to fix first and allocate time for it.

Can automated scanners replace a manual review?

They cannot. Scanners support continuous assurance in the pipeline and find known classes of weakness, but OWASP notes that manual code review finds defects in application logic and data flow that tools may miss. The strongest approach uses both.