ASVS
ASVS copied to clipboard
Extending ch.14.1 towards Ephemerality requirement (ASVS5)
Current Chapter 14 tackles Build and Deploy systems, specifically describing in 14.1.1:
Verify that the application build and deployment processes are performed in a secure and repeatable way, such as CI / CD automation, automated configuration management, and automated deployment scripts. as a requirement for L2 or above.
As supply chain attacks have been occurring/detected more over last few years now, there is a requirement which I think is not reflected by the current wording and usually being encapsulated by the word ‘ephemerality’.
The concern there is that reusing any part of the system which is not ephemeral leads to attacks targeting this mechanism while residing as persistent threats on CI/CD systems.
To better cover this requirement, we can either re-word 14.1.1 to reflect this notion or create a new section, targeted at L3, to emphasize the riskier applications’ concern and dictate ephemeral build systems explicitly.
Personally, I tend towards the latter, but I can imagine the alternative being more elegant to some, especially if you see ephemerality fitting to a L2 requirement.
I would love to have your feedback on the matter
I'd support this with the wording that verification is to a point in time.
Issue https://github.com/OWASP/ASVS/issues/1108 is related.
@cmlh thanks for the input, care to elucidate on how you see verification in a point in time will satisfy the requirement?
I propose the following change:
- Split 14.1.1 into a new requirement that restricts ephemeral hosts to Level 1 and that verification is up until a point in time.
- Modify 14.1.1 to highlight a permanent/indestructible hosts while retaining Level 2 and Level 3.
Is the above a reasonable approach @moshe-apiiro?
for the first point - ephemerality is usually seen as a stricter rule than permanent hosts, hence I can't seem to fit the Level 1 requirement you are proposing also, as for the second point you suggested modifying 14.1.1 - isn't it contradicting L1?
I might be overcomplicating it or tangled in my own terminologies here, though, so excuse me if I'm missing a crucial point in what you are conveying
I proposed Level 1 for ephemeral hosts as they represent a less mature CI pipeline.
I've edited https://github.com/OWASP/ASVS/issues/1315#issuecomment-1186051905 to represent a single change of 14.1.1.
Ephemeral CI agents are perceived as a more mature pipeline as they are more resilient to supply chain attacks (lowers the attack surface and virtually nullifies persistency attacks on those agents/hosts). Do you see it otherwise or under a different prism as less mature CI pipeline?
A majority of my supply chain attacks rely upon ephemeral infrastructure.
The agenda of DevOps is to promote ephemeral CI as more mature.
Therefore, https://github.com/OWASP/ASVS/issues/1315#issuecomment-1186051905 could be reworded so that ephemeral and fixed CI are two separate ASVS Requirements regardless of the DevOps CMMI Maturity Level.
I was also thinking this issue may be more related to the "Build Environments" section of the Software Component Verification Standard (SCVS).
Do you mind if I raise this issue there also @moshe-apiiro?
We should get an alignment on the topic and settle on the main ideas, then let's proliferate to other projects as well.
@cmlh I find your statement peculiar, can you share more about why ephemeral systems are less secure approach for build systems? the statement seems to contradict other standards as well, at least as far as I understand your statement for now.
hi @moshe-apiiro,
Whilst I agree that something like this would seem to be a sensible level 3 requirement, I am a little concerned that we are potentially duplicating ground covered by both OWASP SCVS and also SLSA.
@jmanico @elarlang @danielcuthbert, what are your thoughts on build environment controls? Do you think we should be explicitly including this (as we did in 4.x) or do you think we should be leaving it to other standards? I note that SLSA still appears to be in a pre-release state and OWASP SCVS was last updated 1.5 years ago.
We should consider deprecating 14.1.1 so there is no duplication with SCVS?
Build - Ephemeral are defined as SLSA 3 and SLSA 4.
I wouldn't say this would be an L3 addition at all, I mean I feel L3 is the nuclear option (literally) as it's super expensive and out of reach of most. This feels like an L2 addition and yes, I think it needs to be a brand new requirement for 5.0 given the times we now live in.
To answer your question @tghosth I do think we still need to have this in here, it's that important
@elarlang @jmanico , Daniel has said that build environment controls should stay in v5 of ASVS, what do you think?
Build controls seems more like architedcture and infrastructure, something I think we want to push off to a different standard. Also, I do not (at all) need special build controls to be secure, it's nice but not necessary.
https://github.com/cider-security-research/top-10-cicd-security-risks
Tricky one. Daniel says yes and Jim says no
@elarlang what do you think?
@elarlang any thoughts on this?
@set-reminder 2 days look at this
⏰ Reminder Friday, December 9, 2022 12:00 AM (GMT+01:00)
look at this
I think the real value is that all builds are run in an environment that is in a known good state. And that there is some isolation so that they shouldn't be affected by other builds running on the same host. Running builds in ephemeral containers are just a relatively easy way to achieve that.
@coderpatros I think it would be hard to be sure of this without the ephemeral aspect of the build process.
I think this topic has definitely caused some split opinions both among the leaders and among the volunteers.
Based on everyone's comments and discussions, my conclusion is that I think that it is important that v14.1 remains in some form in ASVS 5.0. Whilst there may be emerging standards related to build process that are more detailed and specific, I think it is important that we will maintain some high level requirements on this topic.
As such, @moshe-apiiro I would be open to a draft of L3 requirements on this topic. The requirements should be clear but relatively high level.
Thanks everyone for your input.
@set-reminder 3 weeks @tghosth to check progress on this issue
⏰ Reminder Wednesday, January 4, 2023 12:00 AM (GMT+01:00)
@tghosth to check progress on this issue
@tghosth please review attached PR suggestion, per our resolution - written as a L3 requirement set at 14.1.8.