Request for a bit more explanation
commjoen opened this issue · comments
Congrats on the new release! Looks really useful!
I do wonder about a few requirements (See below): can you help me understand what they mean? It would be great if the document can provide a bit more explanation on them!
2.8: SBOM is analyzed for risk ; what type of risk? is that development risks ? (e.g. continuity due to often changing signature of the functions it provides?) or only security risk? Or project continuity risk (e.g. license removed, etc.)
2.11: SBOM contains metadata about the asset or software the SBOM describes : what type of metadata are we talking about :) ?
3.9; Application build pipeline prohibits alteration of certificate trust stores ; if you do infrastructure as code and use a 4-eyed/hardened/etc. gitlab configuring pipeline which triggers a certificate manager from the underlying infrastructure to update trust-stores... then that is a lot safer than doing it my hand ... Ofcourse the requirement says application build pipeline, but i wonder: is there a split between configuration pipeline/application pipeline/infra pipeline?
4.6: Package repository supports security incident reporting ; where should it report to?
4.18: Package manager does not execute code : do you mean of the packages that it stores, because a lot of the functionality described is only available when you "upgrade"/"install plugin X for manager Y", etc.?
I love the standard already; it helps explaining what people should expect from the component management side of things! Will you incorporate something like a verification guide and/or a compliancy list like at the MSTG does for the MASVS? Then it could be easily incorporated into existing standardization processes!
Excellent questions.
2.8: SBOM is analyzed for risk ; what type of risk? is that development risks ? (e.g. continuity due to often changing signature of the functions it provides?) or only security risk? Or project continuity risk (e.g. license removed, etc.)
This is intentionally non-prescriptive. The type is risk analyzed is determined by the risk concerns of the organization implementing SCVS and the SBOM format chosen. CycloneDX specializes in security use cases but can be used for most OSS licenses cases as well. SPDX specializes OSS license and intellectual property use cases, and SWID specializes in license entitlements and asset inventory use cases. The type of risk organizations care about will help guide them to an SBOM standard capable of representing the being analyzed for that type of risk. Much of this is covered in the NTIA docs listed in the appendix, specifically the work of the framing group.
2.11: SBOM contains metadata about the asset or software the SBOM describes : what type of metadata are we talking about :) ?
Again, this depends. Sometimes, the only thing that may be available is the name and version of the component. Other times, you'll have pedigree, provenance, license, copyright, individual file info, external references, and dependency graphs. Often times, you'll have a small subset of that. The type and quality of data greatly depends on how the SBOM was generated (e.g. via build using a package manger, or manually from a supplier with opaque information). The type of information that can be captured is also a function of the SBOM standard chosen.
3.9; Application build pipeline prohibits alteration of certificate trust stores ; if you do infrastructure as code and use a 4-eyed/hardened/etc. gitlab configuring pipeline which triggers a certificate manager from the underlying infrastructure to update trust-stores... then that is a lot safer than doing it my hand ... Ofcourse the requirement says application build pipeline, but i wonder: is there a split between configuration pipeline/application pipeline/infra pipeline?
For infrastructure as code, as long as the expected state of the trust store matched the actual state when the build is occurring, then you'd meet this requirement. I think there may be an opportunity to clarify this requirement in the standard.
4.6: Package repository supports security incident reporting ; where should it report to?
This is intentionally non-prescriptive. It would make sense for reporting to be sent to the package repository itself. Sometime this will be a centralized organization like Maven Central or NPM, but other times it may not be easily achievable due to the decentralized nature of the system. For private repositories, reporting should likely be documented by the organization providing the service.
4.18: Package manager does not execute code : do you mean of the packages that it stores, because a lot of the functionality described is only available when you "upgrade"/"install plugin X for manager Y", etc.?
Resolving components is a core functionality of the package manager. Preventing the package manager from executing arbitrary code however is what this standard describes. The package manager should not be allowed to cat /etc/passwd for example as that is outside the scope of what a packager manager is suppose to do. We realize that not all open source or commercial solutions meet all requirements and that some package managers are designed in a way which violate separation of concerns by including traditional installer functionality. This is also by design. However, the group many need to discuss the level for this requirement.
A testing guide would be extremely difficult to achieve. Every org is different. If one would scope the problem to solely use of components from build systems with package management, then that may be achievable. However, many of the tests are at the operating system or network level, rely on data from upstream suppliers, or are organizational behaviors. So it's a bit different from other OWASP verification standards.
Thank you for your elaborate and well explaining response! Maybe it would be a good idea to put some of your explanations in some sort of Q/A or FAQ? Because I am sure others might have different interpretations here as well and then organizations might end up discussing interpretations instead of the good practices the standard recommends.