OWASP
Building on ASVS 5.0 to provide a better 'how' for Developers
First, I want to thank everyone for the amount of work and thought leadership that’s gone into ASVS 5.0. I know how much effort it takes to maintain such a rigorous standard, and I have respect for the direction chosen with an emphasis on verification clarity, abstraction, and risk alignment.
That said, I want to share a concern that’s been growing over the years as the ASVS has evolved—and offer a constructive path forward.
The Heart of the Concern
As someone who has spent much of my professional life educating developers on secure coding, I’ve seen firsthand how difficult it is for developers to take action on abstract requirements. Many of the recent philosophical shifts in ASVS - moving away from prescriptive guidance and toward high-level verification goals - have made the standard significantly less actionable for developers in the trenches writing code. Many of the architects and developers I work with who watch our work have made the observation.
While I understand and appreciate the decision to focus the ASVS on what to verify rather than how to build, I believe this approach unintentionally distances us from one of our most important audiences: developers.
Why This Matters
In its current form, ASVS v5 is an excellent resource for security architects, auditors, and testers. But developers - those closest to the software itself - need something more tactile. A line like “Verify that output encoding is applied contextually” means little without knowing how to do it safely in React, Spring, .NET, or Django.
By creating a structured, developer-friendly supplement, we help secure development without diluting the integrity of ASVS as a verification framework.
Path Forward
Some suggestions to help developers write more secure code could include: • A new project under the OWASP umbrella, D-ASVS • A 4th column in ASVS tables dedicated to developer implementation advice, • Or a companion repository aligned by section and requirement ID. I’m open to the format that makes the most sense for the community and its governance.
Let me give you an example. ASVS 5.0 Requirement
5.3.3 Verify that output encoding is applied contextually to all untrusted data, such that it is safe for the specific interpreter.
I find this to be unfortunately unactionale by a developer.
This is more what I feel developers need to write secure code.
In a React application: Use JSX interpolation ({}) which automatically escapes HTML. In Java/JSP: Use the OWASP Java Encoder: Encode.forHtml(content) for HTML context, Encode.forHtmlAttribute(value) for attributes. Etc.
I authored a series of reqirements that went in this direction but they were removed because they were too specific. But I felt that was the right way to move ASVS forward. But I realize that other leaders felt differently.
How can we somehow use the power of ASVS to help developers better?
My main point of view is of a security-minded software developer foremost (doing some architecture work as well) who happens to stumble upon security issues and who would like to have a simple and actionnable document usable by peer developers. This guide should be usable by the developer, the peer reviewers and not only by architects and pentesters. First of all because in many, cases the developer and the peer reviewer are the only people who are going to actually make these verifications.
If we take the example you gave,
5.3.3 Verify that output encoding is applied contextually to all untrusted data, such that it is safe for the specific interpreter.
I agree that it might be difficult to parse by developers. The requirements should certainly be easier to understand than that, more practical. The requirement should certainly mention the word "injection" somewhere at least.
What I would like to say is more something like (maybe):
Verify that the application correctly encodes content inserted in documents (such as HTML or XML documents) in order to prevent injection attacks. The application must use the a suitable encoding method (eg. HTML encoding, XML encoding) for the type of document and context within the document.
A line like “Verify that output encoding is applied contextually” means little without knowing how to do it safely in React, Spring, .NET, or Django.
One problem is that they are many technologies. Even if we only list the major ones, we will end up having each requirement being followed by a big chunk of examples. That's why I mentioned the idea of a "ASVS companion" document which would expand each requirement with advices and examples from different languages:
Having a list of example of dangerous serialization technologies would be nice but feels weird in the requirement. It would be better be found in some "ASVS companion" document :)
Such a think would be a major undertaking however.
In this example, the ASVS would contain a list of technologies/libraries/frameworks and for each could include things like:
- a list of dangerous functions/methods;
- a list of safer alternatives (when applicable);
- a list other protection measures;
as well as generic guidances.
On this topic, maybe I was wrong when I said that:
Having a list of example of dangerous serialization technologies would be nice but feels weird in the requirement.
Maybe we should actually include some examples after all in order to make the requirement more concrete.
These are really good thoughts @randomstuff and I mean no disrespect. I'll read your comment again soon and provide better feedback.
My point is simply, the more abstract you make any requirement wether it's functional or security, the less useful or actionable it is to developers.
And we made a choice long ago to focus on the more abstract, and by doing so it's a lot harder for developers to parse the requirements. This is not a blame or an attack on anyone, it's just the nature of abstract requirements.
Hi @jmanico ,
I would have prefered that the leaders aligned on this privately before opening it up like this but now that we are here, I have some comments. (I am writing this quickly as I am not highly available today and I would also like to note that I used some info from @elarlang to prepare this response).
BLUF: The ASVS has two primary audiences, developers and "verifiers" and we are constantly trying to make sure requirements address those two audiences. For developers, we should look to better couple the ASVS with the Cheat Sheets project.
Developer focus of the ASVS
The ASVS has two primary audiences, developers and "verifiers" and we are constantly trying to make sure requirements address those two audiences.
I am generally focused on how developers can use the standard. For example, I developed this talk which I delivered multiple times in multiple countries and also personally invited @irene221b to come and deliver this talk at the ASVS community day in Lisbon. All focused on use by developers.
At the same time, I do not see the goal of the ASVS is to be the single authoritiative reference on secure coding, covering every major language. Correct me if I am wrong but I do not believe that this been the goal of any previous ASVS version either, including the versions which myself and Elar were not leaders for.
The ASVS has always been a very large document and to a certain extent has grown even larger in 5.0. Regardless of whether it is practically possible, trying to include detailed implementation information on the face of the standard would grow the standard to an unmanageable monolith that would potentially never be finished and therefore be unable to function as a static standard.
Some specific responses
Let me give you an example. ASVS 5.0 Requirement
5.3.3 Verify that output encoding is applied contextually to all untrusted data, such that it is safe for the specific interpreter.
I find this to be unfortunately unactionale by a developer.
As Elar pointed out to me, this is not how the requirement currently appears in ASVS and we can't actually figure out where this wording came from as it doesn't seem to have been a previous wording either.
The requirement currently appears as follows:
"1.2.1 - Verify that output encoding for an HTTP response, HTML document, or XML document is relevant for the context required, such as encoding the relevant characters for HTML elements, HTML attributes, HTML comments, CSS, or HTTP header fields, to avoid changing the message or document structure."
This is clearly already more specific and I know that there was a long and passionate discussion around how to get this requirement actionable, verifiable, and also within the space of a single requirement.
I authored a series of reqirements that went in this direction but they were removed because they were too specific.
I don't remember this specific discussion and if you could point me to the relevant issue, I think it would help me to understand slightly more of the context around your concerns.
Path Forward
How can we somehow use the power of ASVS to help developers better?
Yes, we can and will. Developers are a first class citizen in ASVS alongside verifiers but they will not necessarily find every answer to every subtle question and edge case here.
To me there is a clear path forward which is better coupling between the OWASP Cheat Sheets project and the ASVS.
Someone, (I think it was @righettod), created a mapping of ASVS 4.0 sections to cheat sheets which is absolutely fantastic and I was super happy they did that.
However, for 5.0 I would like to see a closer coupling between the two projects and I am hoping that a mapping between OpenCRE and ASVS (which is not critical path for the 5.0 release but is something I would like to see soon afterwards) will help to facilitate that.
(In certain cases, where I have felt that information in ASVS was too detailed, I have PRed it into the relevant cheat sheet).
At this point, there are a lots potential spinoffs we could see from ASVS 5.0. Aside from what we can do for developers, I know there is a lot of interest in a more detailed testing guide, I know Diniz wants to make it into a graph database, @irene221b did some cool work around using vector search and AI to help pull out relevant requirements, etc, etc.
There is an absolutely ocean of possibility for using the ASVS as a springboard to help our key developer and verifier audience as well as many others.
But, the Number 1 critical path item to be able to achieve any of that is to be able to release a new stable version upon which all of that can be built and which all of our energy is currently being invested in.
Well first off all I am looking at an older branch and I apologize.
What a horrible example.
Let me give you a few more examples of what I'm talking about. I'll be back to this thread.
And yes, I do want to codify some of the cheat sheet series type rules so developers have more actionable requirements. This might be a companion guide or a separate project.
Again, I'll be back with better examples shortly.
I'm not sure further examples change my response, my point remains the same.
One key thing that I am struggling with, why do you need a separate project if you already have the cheat sheet project?
The cheat sheets are basically a huge encyclopedia. Developers I work with asked for a standard on how to do security in a standardized form.
And as we've talked about, the philosophy of ASVS is not about discussing the how, and it's a gap. It makes it quite challenging for developers to take these ideas and implement them in projects.
I know you've done a lot of hard work on ASVS to help developers - but the abstract nature of the requirements - not something I am suggesting we change - is a gap when we put this into the hands of developers, especially devs new to security.
So I'm brainstorming what to do next. A companion dev guide to ASVS? A second standard?
My goal is to give developers actionable advice on security. The "how".
Hi @tghosth
Someone, (I think it was @righettod), created a mapping of ASVS 4.0 sections to cheat sheets which is absolutely fantastic and I was super happy they did that.
Yes it was me, at the origin, during my work on the project some years ago 😉
Well first of all I am responding to email from developers in the field. And I cited an older requirement (because older text was sent to me) and I do not blame @elarlang and @tghosth for jumping on me for that. Let me try again - and this time I'll cross-reference the latest ASVS requirements. This cited text is the latest text from April 18, at around 8am PT.
And I am not asking anyone to act on this. I just giving you an idea why I made such scandalous comments and the kind of feedback I'm getting from developers who are reviewing our work. And many of these I worked on my self, so as Britney Spears once sang, "I am not that innocent".
2.2.3 Verify that the application ensures that combinations of related data items are reasonable according to the pre-defined rules.
As is, this is almost completely un-actionable to developers or testers. These rules are often not documented. I think we can make this more actionable stand-alone without other references.
3.1.1 Verify that application documentation states the expected security features that browsers using the application must support (such as HTTPS, HTTP Strict Transport Security (HSTS), Content Security Policy (CSP), and other relevant HTTP security mechanisms). It must also define how the application must behave when some of these features are not available (such as warning the user or blocking access).
This is a documentation requirement that expects a list of browser security features and contingency behaviors, but it doesn’t guide the developer on specifics. A developer might not know which CSP directives or HSTS settings are “expected” or how exactly to warn users if, say, HSTS is unsupported.
4.1.3 Verify that per-message digital signatures are used to provide additional assurance on top of transport protections for requests or transactions which are highly sensitive or which traverse a number of systems.
This requirement suggests an extra layer of security (digital signatures) but doesn’t specify when or how to implement it. The phrases “highly sensitive” is subjective. A developer might wonder: does this apply to all API calls, or only certain ones? Implementing per-message signatures can be complex (involving key management, signing algorithms, verifying signatures in each component). Without examples (e.g., signing a JSON payload with HMAC-SHA256) or thresholds (which transactions count as “highly sensitive”), teams may skip this due to uncertainty.
V7.3.1 Verify that there is an inactivity timeout such that re-authentication is enforced according to risk analysis and documented security decisions
Tying session timeouts to a “risk analysis and documented security decisions” is very high-level. Developers are left without a number or range to implement like we used to have. In practice, most would pick an arbitrary timeout (like 15 minutes), but the requirement hints that it should be based on a risk assessment which they may not have. Also, referencing “documented security decisions” means if those documents are missing or unclear, the developer has no guidance. This makes it hard to act on, because it defers the requirement once again to an external process (a risk analysis) that developers might not be involved in.
V8.2.4 Verify that adaptive security controls based on a consumer's environmental and contextual attributes (such as time of day, location, IP address, or device) are implemented for authentication and authorization decisions, as defined in the application's documentation. These controls must be applied when the consumer tries to start a new session and also during an existing session.
(this is one that I worked on that one of my dev's complained about) This requirement asks for adaptive security controls (often known as risk-based or context-based authentication), which is a sophisticated feature. It doesn’t specify which attributes or how to adapt decisions. A developer might be unsure how to implement this : should they deny login from unusual locations, or require MFA if the time or IP is odd? Phrases like “as defined in documentation” push the burden to have a policy document; without one, it’s unclear what to do. Implementing continuous checks “during an existing session” also implies ongoing risk evaluation, which is complex to build without guidance.
12.1.2 Verify that only the latest recommended cipher suites are enabled, with the strongest cipher suites set as preferred. L3 applications must only support cipher suites which provide forward secrecy.
No tool vendor, pentester or developer can act on this. It's way too abstract and requires going deeper into tons of other documentation that is a moving target.
12.1.5 Verify that Encrypted Client Hello (ECH) is enabled in the application's TLS settings to prevent exposure of sensitive metadata, such as the Server Name Indication (SNI), during TLS handshake processes.
Enabling ECH is a bleeding-edge feature that depends on TLS library and client support. For many developers, this is not something they can control in the application code if their server or CDN doesn’t support it.
V14.1.1 Verify that all sensitive data created and processed by the application has been identified and classified into protection levels, and ensure that a policy is in place on how to deal with sensitive data. Note that this includes sensitive data that is being encoded in a recoverable form such as Base64 and JWT. Protection levels need to take into account any data protection and privacy regulations and standards which the application is required to comply with.
This reads more like an organizational or governance requirement than a coding task. It asks for identifying all sensitive data and having a policy for it – which is typically done by a combination of security teams and privacy officers. For an individual developer, this is hard to act on because it requires a full data inventory and classification scheme (which might not exist yet).
16.3.4 Verify that the application can detect and log unusual activity, including business logic anomalies and abnormal or excessive request patterns, such as by IP, user, total per hour or day, based on documented limits.
I need specific limits to act on this as a developer. I need to dig into other documentation to act on this. We're discussing it now https://github.com/OWASP/ASVS/issues/2963
15.4.1 Verify that only thread-safe types are used in multi-threaded contexts, or that non-thread-safe types are synchronized to prevent race conditions.
This is super hard to implement or even test. Developers specifically do now know which classes/modules are safe in their stack.
By stripping the prescriptive “how,” ASVS 5.0 clarifies that it is a verification standard - yet every place where a requirement relies on external documentation, moving industry lists, or undefined thresholds, developers are forced to invent their own “how.” In practice that leads to problems like:
- Inconsistent implementations across teams
- Audit theatre - meeting the letter of “verify” while missing the spirit of security. (The hamster wheel of pain)
- Tool‑misalignment - linters/scanners cannot flag an issue without explicit rules.
2.2.3 Verify that the application ensures that combinations of related data items are reasonable according to the pre-defined rules.
I agree that the wording on this one is quite abstract. 😄
I cannot really make sense out of it without context (we are in V2.2 Input Validation). Even with context, it is quite abstract.
4.1.3 Verify that per-message digital signatures are used to provide additional assurance on top of transport protections for requests or transactions which are highly sensitive or which traverse a number of systems.
I don't like requiring that kind of things to much for what it's worth. It introduces a huge pile of complexity, things which are quite difficult to implement correctly. You might end up having a broken signature implementation because of “it's required” (or you might end up relying on some provider who is going to give you some commercial/closed-source off-the-shelf solution you are not going to be able to understand, or audit properly, and you are going to use badly). In many cases, you might better spend the effort, time and money on something else.
12.1.2 Verify that only the latest recommended cipher suites are enabled, with the strongest cipher suites set as preferred. L3 applications must only support cipher suites which provide forward secrecy.
No tool vendor, pentester or developer can act on this. It's way too abstract and requires going deeper into tons of other documentation that is a moving target.
Pentesters can and should definitely act on this:
- For the server side, SSL server test will give you the list of supported ciphersuites and their rating.
- ciphersuites.info will give you a rating of the different ciphersuites.
- The ASVS appendix gives guidance on selecting ciphersuites.
I'm not a pentester but I have already spent some time checking and configuring ciphersuites on servers in order to achieve this kind of goal and I think this is quite normal to verify that.
This is a moving target but that is not a bad thing. It must be a moving target. You can be compliant today but in one year, you won't be compliant anymore because some ciphersuites have been found to be broken or because of some PQC breakthrough. This is normal.
If, as a developer, you cannot do anything about it (because it depends on the configuration of the reverse proxy and you have no control on that), then it is outside the scope of the verifications you need to do (and things you have to care about). You can safely ignore it. Good for you!
If as a developer, you have hardcoded TLS_DH_RSA_WITH_AES_128_GCM_SHA256 in your client code when doing REST API or WebService calls, you can care about this verification and by checking this requirement you will might notice that you do not support forward secrecy.
If, as a devops, you can have control on the ciphersuites, this is a verification that you should care about. The Mozilla SSL server Configuration Generator can help you get a good configuration. You spend one minute checking that someone did not hardcode old ciphersuites 10 years ago and that this configuration is till not lingering now in production.
12.1.5 Verify that Encrypted Client Hello (ECH) is enabled in the application's TLS settings to prevent exposure of sensitive metadata, such as the Server Name Indication (SNI), during TLS handshake processes.
Enabling ECH is a bleeding-edge feature that depends on TLS library and client support. For many developers, this is not something they can control in the application code if their server or CDN doesn’t support it.
I agree that this is a problem. ECH support is not available in any OpenSSL release and is not available in NGINX for example.
15.4.1 Verify that only thread-safe types are used in multi-threaded contexts, or that non-thread-safe types are synchronized to prevent race conditions.
This is super hard to implement or even test. Developers specifically do now know which classes/modules are safe in their stack.
This may be difficult to verify entirely.
In many cases, you can still verify it and report that you did not find any thread safety issue (without being able to guarantee that there is definitely no thread safety issue).
If you found some thread safety issues, you can point out that you found some thread safety issues and that this might possibly be exploitable in some what (even if you did not find any exploit).
If the code is using threads and modules whose status wrt. thread safety is unknown, you could report that the thread safety status of the application is uncertain and that it might be interesting to clarify it.
If you are doing black box testing, you are going to have a hard time doing a verification of great value on this topic.
V8.2.4 Verify that adaptive security controls based on a consumer's environmental and contextual attributes (such as time of day, location, IP address, or device) are implemented for authentication and authorization decisions, as defined in the application's documentation. These controls must be applied when the consumer tries to start a new session and also during an existing session.
FWIW, I don't like requiring this one very much.
V7.3.1 Verify that there is an inactivity timeout such that re-authentication is enforced according to risk analysis and documented security decisions
Tying session timeouts to a “risk analysis and documented security decisions” is very high-level. Developers are left without a number or range to implement like we used to have. In practice, most would pick an arbitrary timeout (like 15 minutes), but the requirement hints that it should be based on a risk assessment which they may not have. Also, referencing “documented security decisions” means if those documents are missing or unclear, the developer has no guidance. This makes it hard to act on, because it defers the requirement once again to an external process (a risk analysis) that developers might not be involved in.
As a developer/devops, we can say:
- We used a 6 hours timeout because our application is just a silly game / a learning applications.
- We used a 15 minutes timeout because we are managing sensible PII.
- We used a 6 hours timeout because we are managing sensible PII but our users are very very busy.
All of these are very crude risk analysis …
By stripping the prescriptive “how,” ASVS 5.0 clarifies that it is a verification standard - yet every place where a requirement relies on external documentation, moving industry lists, or undefined thresholds, developers are forced to invent their own “how.
I think that these are all unavoidable of sort (especially for the "moving industry list").
- relies on external documentation → I'm not a super fan of the "verify that X is documented" + "verify that X behaves as documented" indirection very much.
- moving industry lists → As said before, I think this is unavoidable of sort. Cryptography is a moving target that still needs to be followed.
- undefined thresholds → I think it might be difficult to mandate hard thresholds (eg. for timeout durations).
Notes on the examples
I read through the examples. Certainly each got to where it is now through extensive discussion but where you think there are specific concerns about the understandability of specific requirements, now is the time to go back through the issues, find the original discussion and open it back up if necessary. Certainly at least two of the requirements you highlighted need clarifying, regardless of the philosophy of ASVS.
Responses to specific points
The cheat sheets are basically a huge encyclopedia. Developers I work with asked for a standard on how to do security in a standardized form.
I would have thought that the cheat sheets are the "how" and the standardized form is just a question of improving the coupling between the two projects.
By stripping the prescriptive “how,” ASVS 5.0 clarifies that it is a verification standard...
Respectfully, I don't think the ASVS has ever been considered the single how-to for security, even in previous versions and therefore I don't think this is something that has been stripped. It has always been designed as a basis upon which to build.
I know you've done a lot of hard work on ASVS to help developers - but the abstract nature of the requirements - not something I am suggesting we change - is a gap when we put this into the hands of developers, especially devs new to security.
So I'm brainstorming what to do next. A companion dev guide to ASVS? A second standard?
So if I understand correctly you are talking about some new resource that would have the structure of ASVS but at at far more detailed level?
I think that we were worried that you were coming out against ASVS whereas if I understand correctly, you support the ASVS but you are trying to think what could be added on top to make it even more useful. (I would also point out that we have had a lot of feedback that people would like to see a more detailed testing guide for ASVS and this is something we are hoping can also be built on top of the 5.0 release)
If I have understood you correctly, I would therefore respectfully suggest that the thing to do next is to get a solid update to the ASVS out, in line with the philosophy that the ASVS has always had, and then look at what can be built upon that.
To get this out we need your help and expertise to make sure that we build a solid base for whatever comes next and most of all we need your support for the current release candidate and your drive to help us focus on this final push to finish.
If you agree, would you be comfortable to do the following:
- Rename this issue to something like "Building on ASVS 5.0 to provide a better 'how' for Developers"
- Mark this issue with the "non-blocker" label
- Reopen the relevant issues for any requirement concerns noted above, or open a new issue for each, referencing any previous discussion?
Certainly each got to where it is now through extensive discussion
One of my core beliefs @tghosth is that a good requirement should stand alone and be clear. If I need to "go back and read the debate" on how we got that that conclusion or I need to read other documentation to understand a requirement, then I think to some degree we have failed.
The "stand alone" requirement principle is one of my core beliefs about ASVS as a lifelong developer. And many of our requirements do not meet that criterial. And that goes for much of my own work here is well. I am not passing any blame.
I also do not mind a ASVS 5.0 RC2 release soon, but I am very opposed to releasing ASVS 5.0 final until we have had more developer review. I am getting a lot of that feedback now and will open new issues based on that feedback.
If I need to "go back and read the debate" on how we got that that conclusion or I need to read other documentation to understand a requirement, then I think to some degree we have failed.
I think you are conflating a few things here, so let me try and split them out here.
-
As a consumer of the standard, the security goal and high level requirement should be understandable on a standalone basis.
-
The exact action you will need to take to achieve that will depend on your language, framework, architecture, and many other things that are beyond the scope of ASVS
-
If a project leader, working group member or RC1 reviewer is questioning why a requirement is worded the way it is worded, that is when it is necessary to go back to the issue where it was discussed, as you said yourself in your slack message: "Also, before submitting, please search the issue tracker for the requirement you're commenting on to see if there's already an ongoing or past discussion. A little research goes a long way and makes your contributions even more impactful."
I also do not mind a ASVS 5.0 RC2 release soon, but I am very opposed to releasing ASVS 5.0 final until we have had more developer review. I am getting a lot of that feedback now and will open new issues based on that feedback.
The review period is now and has been open since that start of the month, we will make an effort to respond to and/or action feedback received before the end of the month (with priority being given to feedback based on the research you mention above).
I think you are conflating a few things here, so let me try and split them out here.
- As a consumer of the standard, the security goal and high level requirement should be understandable on a standalone basis.
- The exact action you will need to take to achieve that will depend on your language, framework, architecture, and many other things that are beyond the scope of ASVS
- If a project leader, working group member or RC1 reviewer is questioning why a requirement is worded the way it is worded, that is when it is necessary to go back to the issue where it was discussed, as you said yourself in your slack message: "Also, before submitting, please search the issue tracker for the requirement you're commenting on to see if there's already an ongoing or past discussion. A little research goes a long way and makes your contributions even more impactful."
I understand your points clearly and appreciate the breakdown. However, I don’t feel I'm conflating these issues. Let me clarify my perspective:
I strongly agree that it's beneficial—and often necessary—to revisit past discussions on individual requirements. I encourage everyone, myself included, to consistently research requirements to understand context and intent. However, I firmly believe that each requirement should inherently be clear and understandable on its own. The more I have to repeatedly revisit past discussions or documentation to comprehend a requirement - is itself an indicator of a problem. Ideally, minimal research should be necessary to grasp the meaning and intent of a requirement clearly. This principle is fundamental, not just to security, but to functional and other forms of requirements I've encountered in my 30-year career. Clear, self-contained requirements ultimately lead to better adoption, fewer misunderstandings, and more effective security implementation.
I also do not mind a ASVS 5.0 RC2 release soon, but I am very opposed to releasing ASVS 5.0 final until we have had more developer review. I am getting a lot of that feedback now and will open new issues based on that feedback. The review period is now and has been open since that start of the month, we will make an effort to respond to and/or action feedback received before the end of the month (with priority being given to feedback based on the research you mention above).
I completely understand your point about the open review period and appreciate all the effort put into responding to feedback thus far. However, I firmly believe that all four project leaders should be fully aligned before we issue the final ASVS 5.0 release. While I agree we are indeed close, I strongly advocate for additional community and developer review before we finalize. I'm actively encouraging and gathering this feedback daily and plan to open other issues as I get more developer feedback.
If substantial additional review doesn't materialize soon, releasing another RC makes sense—but I remain convinced we are not yet ready for a final 5.0 release. I'll continue putting my full effort into help with the review process!
I think we broadly speaking agree on the requirements point and we should handle questions on the clarity of individual requirements in the relevant separate issues.
Following our brief offline discussion about timescales, I will open a formal issue about this although I may wait until after the long holiday weekend.
Developer focus of the ASVS
The ASVS has two primary audiences, developers and "verifiers" and we are constantly trying to make sure requirements address those two audiences.
I am generally focused on how developers can use the standard. For example, I developed this talk which I delivered multiple times in multiple countries and also personally invited @irene221b to come and deliver this talk at the ASVS community day in Lisbon. All focused on use by developers.
FWIW, I think to continuously expand ASVS itself is not the answer; if it can be kept slim and language agnostic I think that's the way forward. Connecting ASVS to OWASP cheat-sheets is something that's been on my mind for a while. I think technologically to do it through graphs and semantic similarity is possible and would work very well. OpenCRE is a good example how to connect things together while keeping each one of them coherent.
FWIW, I think to continuously expand ASVS itself is not the answer; if it can be kept slim and language agnostic I think that's the way forward. Connecting ASVS to OWASP cheat-sheets is something that's been on my mind for a while. I think technologically to do it through graphs and semantic similarity is possible and would work very well. OpenCRE is a good example how to connect things together while keeping each one of them coherent.
There are two things happened here which I think are in conflict, and I am conflicted in this as well.
On one hand I want actionable advice for developers. So I try to push away from abstract requirements that are not actionable.
By another measure, I am trying to trim down ASVS before its next release. Almost 400 requirements (26 of them on documentation alone) is getting ridiculous and almost impossible for anyone to act on.
These ideas are often in conflict. Good developer advice requires a lot of detail. Too much verbosity is also overwhelming.
So I am trying to thread the needle of pointing out abstract requirements and clarify them while also suggesting we remove the lower risk or unactionable requirements. And it's hard. Especially when others want to push this live very soon and are not willing to make major changes at this point.
I really do not want to push ASVS 5 live until we figure this out and get more community feedback.