ASVS
ASVS copied to clipboard
Secure development environments
Not sure this type of thing would be considered in scope or not.
But containerised, reproducible, ephemeral, development environments are now becoming more commonplace. i.e. Gitpod and GitHub Codespaces.
A see them as a natural next step after doing the same for build environments. i.e. the current requirements for V14.1 Build cover.
Any opinions on this?
Looking to ASVS v5.0, the scope question is at the moment really valid for myself - from what step starts application and what is the scope for ASVS.
Also, need to think with larger view and avoid complete overlap with other standards, like for example: https://github.com/OWASP/Software-Component-Verification-Standard
Welcome to the Application Security Verification Standard (ASVS) version 4.0. The ASVS is a community-driven effort to establish a framework of security requirements and controls that focus on defining the functional and non-functional security controls required when designing, developing and testing modern web applications and web services.
From the preface, I see this as a control as part of developing modern applications. And, IMHO, isn't that different to controls being specified for build pipelines. If anything, I think it could be an evolution and extension of those controls.
For my taste "Secure development environment" is away from ASVS scope. Where is that line between "in scope" and "not in scope" is question of discussion.
From pen-test point of view, what could be the list of requirements, are they actually testable? Verify that development environment is secure" is not reasonable, but if to start verifying piece by piece from development environment, if feels too far away from application itself. For sure, it's important part of secure application as final product, but this scope...
I think expanding build and deployment by adding something like these as L3 requirements would be reasonable.
Verify that the application development environment is sandboxed.
Verify that the application development environment is restored from a known good state between units of work.
But completely understand that this might be crossing the line to out of scope.
Should we deprecate https://github.com/OWASP/ASVS/blob/master/4.0/en/0x22-V14-Config.md#v142-dependency for the https://github.com/OWASP/Software-Component-Verification-Standard then?
Should we deprecate master/4.0/en/0x22-V14-Config.md#v142-dependency for the OWASP/Software-Component-Verification-Standard then?
I don't understand what that has to do with these controls?
This is about the environment a developer is using to work on the software. i.e. sandboxing your code, IDE, and local build tools, from other activities like browsing the internet, etc.
It drastically reduces the blast radius of something like the recent ua-parser-js issue.
If I was still preforming https://www.cyber.gov.au/acsc/view-all-content/programs/australian-information-security-evaluation-program and therefore is what Mike Boberski based ASVS ToV on (i.e. Common Criteria) then I'd inspect https://github.com/OWASP/Software-Component-Verification-Standard in addition to https://github.com/OWASP/ASVS/blob/master/4.0/en/0x22-V14-Config.md#v142-dependency
I'll raise a separate issue to explore the differences between https://github.com/OWASP/Software-Component-Verification-Standard to that of https://github.com/OWASP/ASVS/blob/master/4.0/en/0x22-V14-Config.md#v142-dependency (if any) as the first step before a PR unless @coderpatros knows this already and therefore I'll support his Pull Request to list these requirements as L3 too.
For ASVS scope discussion we have #1127 now.
I think this is a good question which will really depend on the outcome of #1127
In the meantime, @coderpatros what sort of requirements would you expect to see in relation to this?
Note that I made another comment on https://github.com/OWASP/ASVS/issues/1127#issuecomment-1193352560
Hi @coderpatros, this was also mentioned in #1315, do you have any opinions on what is written there?
@set-reminder 3 weeks close if no response
⏰ Reminder Wednesday, December 28, 2022 12:00 AM (GMT+01:00)
close if no response
@tghosth I think the comments about this being out of scope for ASVS make sense.
Thank you for ideas and feedback, I'm closing this one.