Are parts of 14.2.x section out of scope for ASVS?

[tghosth]

This is an offshoot from #1405

My original question:

OK, I think the big question here is whether 3rd party library risk is definitely in scope for ASVS v5. We generally consider SSDLC activities and CI/CD processes to be out of scope.

Original response from @meghanjacquot:

If we are removing SSDLC as part of scope, then I think we should rethink all of 14.2. It seems like that if those are out of scope, analyzing 3rd party risk could potentially be as well therefore making all of 14.2 out of scope.

Also, removal of 14.1.1 due to the CI/CD emphasis and 14.1.3 due to 3rd party references.

My 2nd response:

So, sorry for the flip-flopping but I am thinking more about that this. It feels like 3rd party libraries are an inseparable part of writing the application which makes me think that we cannot ignore them entirely.

I do however think that maybe we want the 14.2.x requirements to be as simple as possible. We previously considered splitting client-side and server-side dependency requirements because of testability but I no longer think that is worth two requirements. I also think that we should not be too prescriptive about the specific solution.

So the question at thr moment is: Which requirements from 14.2.x do you we think should stay/go?

[elarlang]

The section as it stands

#	Description	L1	L2	L3	CWE
14.2.1	Verify that all components are up to date, preferably using a dependency checker during build or compile time.	✓	✓	✓	1026
14.2.2	[MOVED TO 14.1.6]
14.2.3	[MOVED TO 50.6.1]
14.2.4	Verify that third party components come from pre-defined, trusted and continually maintained repositories.		✓	✓	829
14.2.5	Verify that a Software Bill of Materials (SBOM) is maintained of all third party libraries in use.		✓	✓
14.2.6	[MODIFIED, SPLIT TO 14.2.8, LEVEL L2 > L3] Verify that risky third party libraries or those with a history of vulnerabilities are encapsulated such that only required behaviour is available to the application, to reduce attack surface.			✓	1061
14.2.7	[ADDED] Verify that third party components are sourced separately from internally owned and developed applications to prevent dependency confusion attacks.	✓	✓	✓	427
14.2.8	[ADDED, SPLIT FROM 14.2.6] Verify that risky third party libraries or those with a history of vulnerabilities are sandboxed away from the most sensitive system modules/services so that even if a vulnerability in the library was successfully exploited, the sensitive system modules/services would not be compromised.			✓	1061

[elarlang]

• 14.2.1 - we need components to be up to date, but we don't need to say how it is checked (remove the second part of the requirement)
• 14.2.4 and 14.2.5 can be merged
• 14.2.4 - what is a "trusted party" for 3rd party component, and how we can measure the "continually maintained" - at the same time, I have used this requirement to report library in use that has known vulnerabilities and no updates for 4 years.
• 14.2.7 - without underestimating the problem, I think it is more about the building (process) the application than the application itself
• 14.2.6, 14.2.8 - we have had this discussion in related issues, but I repeat my question here - how do we measure, what is "risky"?
• 14.2.6, 14.2.8 - related discussion Item number 14.2.6 needs to be revised  #1425
• 14.2.6, 14.2.8 - just as an option - in a way those can be in some separate sandboxing section if needed, I think those are not clear dependency requirements as such.

[randomstuff]

I think 14.2.4, 14.2.5 and 14.2.5 are important (with some remarks).

14.2.1 Verify that all components are up to date, preferably using a dependency checker during build or compile time.

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:

• the dependency does not contain known vulnerabilities (unless we are certain that this vulnerability does not apply in our case);
• the dependency (and the dependency version) is still maintained.

Verify that third party components come from pre-defined, trusted and continually maintained repositories.

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.

Verify that risky third party libraries or those with a history of vulnerabilities are encapsulated such that only required behaviour is available to the application, to reduce attack surface.

[...]

Verify that risky third party libraries or those with a history of vulnerabilities are sandboxed away from the most sensitive system modules/services so that even if a vulnerability in the library was successfully exploited, the sensitive system modules/services would not be compromised

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.

[meghanjacquot]

• 14.2.1 - we need components to be up to date, but we don't need to say how it is checked (remove the second part of the requirement)

• Maybe,
  14.2.1 - Verify that all components are up to date. If there are third party components, verify that they are continually maintained.

Depending on how this is verified it really seems like more of a V1, maybe 1.1.

• 14.2.4 and 14.2.5 can be merged

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)

• 14.2.7 - without underestimating the problem, I think it is more about the building (process) the application than the application itself

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.

• 14.2.6, 14.2.8 - we have had this discussion in related issues, but I repeat my question here - how do we measure, what is "risky"?

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...

• 14.2.6, 14.2.8 - just as an option - in a way those can be in some separate sandboxing section if needed, I think those are not clear dependency requirements as such.

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.

[elarlang]

@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.

[elarlang]

14.2.1

Verify that all components are up to date. If there are third party components, verify that they are continually maintained.

• I agree with comments (@Sjord proposal: remove 1.14.3 as duplicate of or merge to 14.2.1 #1405 (comment) + @randomstuff Are parts of 14.2.x section out of scope for ASVS? #2088 (comment)), that we don't need to require up to date components, but components without known vulnerabilities.
• As we are in the "Dependency" section and talking about components and up to date, then I feel that the special mention for "if the 3rd party component is used" does not give anything extra

14.2.4

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.

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.

[jmanico]

14.2.6, 14.2.8 - we have had this discussion in related issues, but I repeat my question here - how do we measure, what is "risky"?

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.

[jmanico]

14.2.1 Verify that all components are up to date. If there are third party components, verify that they are continually maintained.

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.

[elarlang]

14.2.6, 14.2.8 - we have had this discussion in related issues, but I repeat my question here - how do we measure, what is "risky"?

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.

And if you find it risky, you could use it in a level 3 application as one component?

You miss non published security fixes.

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)?

This is the "updatability"

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.

[jmanico]

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.

[meghanjacquot]

@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.

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?

[elarlang]

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.

[meghanjacquot]

• 14.2.1 - we need components to be up to date, but we don't need to say how it is checked (remove the second part of the requirement)

14.2.1 Verify that components are up to date.

• 14.2.4 and 14.2.5 can be merged

Merge 14.2.4 and 14.2.5

Suggestion: "Verify that a Software Bill of Materials (SBOM) is maintained and that all third party components come from pre-defined, trusted and continually maintained repositories."

• 14.2.7 - without underestimating the problem, I think it is more about the building (process) the application than the application itself

Given this thought process, what do you think of moving 14.2.7 to 14.1.X?

• 14.2.6, 14.2.8 - just as an option - in a way those can be in some separate sandboxing section if needed, I think those are not clear dependency requirements as such.

I think keeping this in 14.2 makes sense. They flow well with the rest of the material in 14.2

Please share any thoughts or ideas for these @elarlang @jmanico @tghosth - thank you!

[jmanico]

14.2.4 and 14.2.5 look very different for me. A SBOM is about maintaining component documentation continuously. Using trusted repositories to get third party components is very different from the SBOM document. SBOM does not guarantee you are using trusted repositories.

[jmanico]

I would suggest merging 14.2.4 and 14.2.7 - those are both about using trusted repositories. My suggestion:

Verify that third-party components are sourced from predefined, trusted, and continually maintained repositories, and are managed separately from internally owned and developed applications to prevent dependency confusion attacks.

[elarlang]

14.2.4 and 14.2.5 look very different for me. A SBOM is about maintaining component documentation continuously. Using trusted repositories to get third party components is very different from the SBOM document. SBOM does not guarantee you are using trusted repositories.

I disagree. During maintaining the SBOM is exactly good thing to validate, are sources trusted and maintained. SBOM (14.2.5) is result of activity from current 14.2.4

I would suggest merging 14.2.4 and 14.2.7 - those are both about using trusted repositories.

I disagree. 14.2.4 is to define, from where you take external components. 14.2.7 is to define where you keep those external components on your side.

EDIT: I misinterpreted the requirement 14.2.7, I agree with the merge proposal, will be handled in #2167

[jmanico]

I disagree. During maintaining the SBOM is exactly good thing to validate, are sources trusted and maintained. SBOM (14.2.5) is result of activity from current 14.2.4

The SBOM standard does not require that you list the source or download URI of the library. It's optional metadata that is often not included. The SBOM standard includes Component Name, Version, Component Type, License Information, Supplier Information, Component Hashes, Dependency Relationships, Unique Identifiers and Author information.

It's not a reliable reference to understand the repository the library came from. That information would typically be tracked in package management or supply chain management systems, not directly in the SBOM itself.

[elarlang]

And if the SBOM does not require it, it means, it is not allowed and not a logical thing to do?

From that "getting stuck into the SBOM declaration", I would say, that SBOM is just one, but not the only, option to handle inventory of 3rd party libraries in use and I propose to turn back to the requirement version we had in v4.0.2:

V14.2.5 Verify that an inventory catalog is maintained of all third party libraries in use.

We can add there "using SBOM" as an example how to achieve it and it can contain current 14.2.4 really well.

[jmanico]

And if the SBOM does not require it, it means, it is not allowed and not a logical thing to do?

Not at all. I am just saying that an SBOM is not a reliable reference to understand the repository the library came from. That's just the nature of SBOM's and it's not their job.

[elarlang]

From the issue goal point of view "So the question at thr moment is: Which requirements from 14.2.x do you we think should stay/go?" I would say, that we did not find any out of scope requirements and we can close this issue.

For each requirement update/merge side-topics I opened a separate issue - here, it is not followable anymore, what is the latest proposal for some requirements:

• 14.2.1 - component up to date #2164
• proposal: merge 14.2.4 and 14.2.5 and move to V1.10 #2165
• Review requirementes 14.2.6 and 14.2.8, potential move to V10 #2166
• V14.2.7 - move to V10 #2167

[elarlang]

Note, each requirement got a separate issue, but in general - dependency is more program code topic than pure configuration. So general recommendation is to move section V14.2 "dependency" to V10.

V10 itself will be with more wide topic, with focus "how to organize program code and checks from program code"

[elarlang]

V10 definition is moved here #2173

[elarlang]

Status update: V10 scope is widened.

At the moment it seems, that in the "Dependency" section we have only current 14.2.1 and probably also current 14.2.7 (#2167).

If there is only one requirement, we need to think what is the suitable section in V10 for current 14.2.1. If there are at least 2, then I propose to move 14.2 Dependency to 10.6 Dependency.

[elarlang]

With issue #2166 requirements 14.2.6 and 14.2.7 (previously 14.2.8) will be merged and moved to the V10 area, or will be binned.

The rest of the V14.2 is cleaned up, close.