-
-
Notifications
You must be signed in to change notification settings - Fork 662
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Are parts of 14.2.x section out of scope for ASVS? #2088
Comments
The section as it stands
|
|
I think 14.2.4, 14.2.5 and 14.2.5 are important (with some remarks).
I think "up to date" is slightly off the mark (or maybe too vague). From a security point of view, I don't need to have eg. the latest Angular version and there is not need to rush to do an upgrade in general. What we want to check is that:
I am not sure what "pre-defined" means in this context. I would drop "continually". I am not sure 14.2.6-8 should be kept.
This is not really specific to third party dependencies. The same could be said of first-party dependencies and components. Maybe, this should be moved/merged into more general requirements in the "architecture" chapter. |
Depending on how this is verified it really seems like more of a V1, maybe 1.1.
14.2.4 - I think this gets covered by 14.2.1 and 14.2.5. If the above updates to 14.2.1 are approved than that would cover things for 14.2.4 and it could be removed. QUESTION: 14.2.5 leave as is, but I wonder if it would be better in a different chapter as it is isn't configuration? Maybe moved to V1, in 1.1? 14.2.6, revise as suggested in #1425](#1425)
I'm in agreement, 14.2.7 does not seem to be as much something that is related to configuration and I think it should be in a different chapter - likely V1.
If both are at level 3, do we concern ourselves with how whoever is using ASVS is defining risky? I think it goes against the idea of being prescriptive with things. We could have some supplemental material at the end of V14, such as relating to Douglas Hubbard book, https://hubbardresearch.com/risk-management-modeling/ But I also don't want to endorse 1 person's text on something...
I like the idea of them being in a different section, so either staying in V14, but becoming 14.7 or moving over to V1 if we're looking at it as more of an building thing. |
@meghanjacquot - note that V1 is for documentation requirements only and is under clean-up process for everything that are not documentation requirements. Most likely all requirements from V1 will end up as separate section into the related category. In short, moving thing to V1 is not a solution here till those are not clear documentation requirements. 14.2.5 can be only theoretical candidate from those. |
14.2.1
14.2.4
14.2.1 is something you check from the program code (based on 14.2.5 information) and 14.2.5 is somehting you check from your documentation, although it can be made as technical solution. 14.2.4 to check, that the source for third party solution is trusted and continually maintained you check from 3rd party documentations, based on information from 14.2.5. So I think it can be and should be merged to 14.2.5. 14.2.5 It can be technical solution, it can be documentation or both. For this I can understand the logic to propose moving to V1, but I'm not really sure about it. edit: thinking more about it - as a security decision to make (which component to use) and document, before implementing, 14.2.5 belongs by content to current V1. |
I think there are plenty of ways to measure this. You can take a look at Snyk's database on a certain libraries and look at the recent security history. Are they continually finding and fixing critical vulnerabilities? That's a bad sign. Was critical vulnerabilities part of the past but less so in the future? That implies they are getting better. Do they have a security list? Do they respond to issues quickly? There are plenty of ways to look up a libraries history in github and snyk and get solid metrics on how "risky" they overall software process is. |
Be careful here. The more you skip non-security updates you run into two problems: a) You miss non published security fixes. I am in the middle on a research project that shows that this is a significant problem for some of the top 500 ilbraries and will publish that report next year. b) The more you skip non-security updates, the more difficult it will be to update that library when a real security updates shows up. This is the "updatability" of a library which gets more and more challenging over time as you skip updates. By the same token, the cost of keeping everything up to date is painful. I would like requirement to stay and acknowledge both sides of this issue. 14.2.1 Verify that all components are up to date. While updating libraries, particularly for non-security reasons, can be costly and resource-intensive, it is still important to stay current. Non-published security vulnerabilities and other hidden issues may only surface in future versions, and keeping components up to date ensures compatibility and ease of future updates, preventing technical debt. |
And if you find it risky, you could use it in a level 3 application as one component?
This is the understandable risk with this wording. At the same time, being quickly up to date is not risk free as well. Another question is, what up to date means - let's take an example from PHP: https://www.php.net/supported-versions.php If you use latest 8.1.* - are you up to date, as this version gets critical security fixes only? If you use latest 8.2.* - are you up to date, as there is also newer version (8.3)?
One should understand, that ability to update and being up to date are different things. I don't think we should go with this educative text in the requirement. |
I used the beefier text just to explain my point in this thread (as opposed to several different threads) before the final decision was made. Thank you for hearing me out.
|
Ahh, so would the idea be to leave things that might go into a future section in V14 for now with the idea being that those will be revised after V1 is revised? |
No need to wait, we can sort things out to "correct baskets". For example, I think 14.2.4 and 14.2.5 should me merged and moved to V1.14. |
This is an offshoot from #1405
My original question:
Original response from @meghanjacquot:
My 2nd response:
So the question at thr moment is: Which requirements from 14.2.x do you we think should stay/go?
The text was updated successfully, but these errors were encountered: