├── .gitattributes ├── .github └── workflows │ └── cibuild.yml ├── .gitignore ├── CNAME ├── LICENSE.txt ├── OWASP_SCVS-1.0-en.docx ├── OWASP_SCVS-1.0-en.pdf ├── OWASP_SCVS-1.0.csv ├── OWASP_SCVS-1.0.json ├── OWASP_SCVS-1.0.xml ├── README.md ├── cover.afdesign ├── cover.docx ├── cover.eps ├── cover.jpg ├── cyclonedx.py ├── en ├── 0x00-Header.md ├── 0x01-Frontispiece.md ├── 0x02-Preface.md ├── 0x03-Using-SCVS.md ├── 0x04-Assessment_and_Certification.md ├── 0x10-V1-Inventory.md ├── 0x11-V2-Software_Bill_of_Materials.md ├── 0x12-V3-Build_Environment.md ├── 0x13-V4-Package_Management.md ├── 0x14-V5-Component_Analysis.md ├── 0x15-V6-Pedigree_and_Provenance.md ├── 0x80-Guidance-Open_Source_Policy.md ├── 0x90-Appendix-A_Glossary.md ├── 0x91-Appendix-B_References.md └── images │ ├── license.png │ └── owasp_logo_1c_notext.png ├── export.py ├── generate-csv.py ├── generate-document.sh ├── scvs.py └── templates ├── pagebreak.lua └── reference.docx /.gitattributes: -------------------------------------------------------------------------------- 1 | # Let git fix markdown files to the appropriate ending for the platform 2 | *.md text 3 | 4 | # Images are blobs. Don't touch 5 | *.jpg binary 6 | *.png binary 7 | 8 | # Make git leave Python and shell scripts alone to prevent bugs when running them under Windows Subsystem for Linux bash 9 | *.py -text 10 | *.sh -text 11 | -------------------------------------------------------------------------------- /.github/workflows/cibuild.yml: -------------------------------------------------------------------------------- 1 | name: CI Build 2 | 3 | on: 4 | push: 5 | branches: 6 | - master 7 | pull_request: 8 | 9 | # Allows you to run this workflow manually from the Actions tab 10 | workflow_dispatch: 11 | 12 | jobs: 13 | build: 14 | 15 | runs-on: ubuntu-latest 16 | 17 | steps: 18 | - uses: actions/checkout@v1 19 | - name: Set up Python 3.7 20 | uses: actions/setup-python@v1 21 | with: 22 | python-version: 3.7 23 | - name: Install dependencies 24 | run: | 25 | wget https://github.com/jgm/pandoc/releases/download/2.9/pandoc-2.9-1-amd64.deb 26 | sudo dpkg -i pandoc-2.9-1-amd64.deb 27 | python -m pip install --upgrade pip 28 | pip install pandoc 29 | - name: Export documents 30 | run: | 31 | python3 export.py --format csv > OWASP_SCVS-SNAPSHOT.csv 32 | python3 export.py --format json > OWASP_SCVS-SNAPSHOT.json 33 | python3 export.py --format xml > OWASP_SCVS-SNAPSHOT.xml 34 | - name: Generate document 35 | run: | 36 | chmod +x generate-document.sh 37 | ./generate-document.sh 38 | - name: Archive CSV export 39 | uses: actions/upload-artifact@v1 40 | with: 41 | name: OWASP_SCVS-SNAPSHOT.csv 42 | path: OWASP_SCVS-SNAPSHOT.csv 43 | - name: Archive JSON export 44 | uses: actions/upload-artifact@v1 45 | with: 46 | name: OWASP_SCVS-SNAPSHOT.json 47 | path: OWASP_SCVS-SNAPSHOT.json 48 | - name: Archive XML export 49 | uses: actions/upload-artifact@v1 50 | with: 51 | name: OWASP_SCVS-SNAPSHOT.xml 52 | path: OWASP_SCVS-SNAPSHOT.xml 53 | - name: Archive document 54 | uses: actions/upload-artifact@v1 55 | with: 56 | name: OWASP_SCVS-SNAPSHOT-en.docx 57 | path: OWASP_SCVS-SNAPSHOT-en.docx 58 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | 2 | *.db 3 | .DS_Store 4 | .vscode/settings.json 5 | *.pyc 6 | -------------------------------------------------------------------------------- /CNAME: -------------------------------------------------------------------------------- 1 | scvs.owasp.org -------------------------------------------------------------------------------- /LICENSE.txt: -------------------------------------------------------------------------------- 1 | Attribution-ShareAlike 4.0 International 2 | 3 | ======================================================================= 4 | 5 | Creative Commons Corporation ("Creative Commons") is not a law firm and 6 | does not provide legal services or legal advice. Distribution of 7 | Creative Commons public licenses does not create a lawyer-client or 8 | other relationship. Creative Commons makes its licenses and related 9 | information available on an "as-is" basis. Creative Commons gives no 10 | warranties regarding its licenses, any material licensed under their 11 | terms and conditions, or any related information. Creative Commons 12 | disclaims all liability for damages resulting from their use to the 13 | fullest extent possible. 14 | 15 | Using Creative Commons Public Licenses 16 | 17 | Creative Commons public licenses provide a standard set of terms and 18 | conditions that creators and other rights holders may use to share 19 | original works of authorship and other material subject to copyright 20 | and certain other rights specified in the public license below. The 21 | following considerations are for informational purposes only, are not 22 | exhaustive, and do not form part of our licenses. 23 | 24 | Considerations for licensors: Our public licenses are 25 | intended for use by those authorized to give the public 26 | permission to use material in ways otherwise restricted by 27 | copyright and certain other rights. Our licenses are 28 | irrevocable. Licensors should read and understand the terms 29 | and conditions of the license they choose before applying it. 30 | Licensors should also secure all rights necessary before 31 | applying our licenses so that the public can reuse the 32 | material as expected. Licensors should clearly mark any 33 | material not subject to the license. This includes other CC- 34 | licensed material, or material used under an exception or 35 | limitation to copyright. More considerations for licensors: 36 | wiki.creativecommons.org/Considerations_for_licensors 37 | 38 | Considerations for the public: By using one of our public 39 | licenses, a licensor grants the public permission to use the 40 | licensed material under specified terms and conditions. If 41 | the licensor's permission is not necessary for any reason--for 42 | example, because of any applicable exception or limitation to 43 | copyright--then that use is not regulated by the license. Our 44 | licenses grant only permissions under copyright and certain 45 | other rights that a licensor has authority to grant. Use of 46 | the licensed material may still be restricted for other 47 | reasons, including because others have copyright or other 48 | rights in the material. A licensor may make special requests, 49 | such as asking that all changes be marked or described. 50 | Although not required by our licenses, you are encouraged to 51 | respect those requests where reasonable. More considerations 52 | for the public: 53 | wiki.creativecommons.org/Considerations_for_licensees 54 | 55 | ======================================================================= 56 | 57 | Creative Commons Attribution-ShareAlike 4.0 International Public 58 | License 59 | 60 | By exercising the Licensed Rights (defined below), You accept and agree 61 | to be bound by the terms and conditions of this Creative Commons 62 | Attribution-ShareAlike 4.0 International Public License ("Public 63 | License"). To the extent this Public License may be interpreted as a 64 | contract, You are granted the Licensed Rights in consideration of Your 65 | acceptance of these terms and conditions, and the Licensor grants You 66 | such rights in consideration of benefits the Licensor receives from 67 | making the Licensed Material available under these terms and 68 | conditions. 69 | 70 | 71 | Section 1 -- Definitions. 72 | 73 | a. Adapted Material means material subject to Copyright and Similar 74 | Rights that is derived from or based upon the Licensed Material 75 | and in which the Licensed Material is translated, altered, 76 | arranged, transformed, or otherwise modified in a manner requiring 77 | permission under the Copyright and Similar Rights held by the 78 | Licensor. For purposes of this Public License, where the Licensed 79 | Material is a musical work, performance, or sound recording, 80 | Adapted Material is always produced where the Licensed Material is 81 | synched in timed relation with a moving image. 82 | 83 | b. Adapter's License means the license You apply to Your Copyright 84 | and Similar Rights in Your contributions to Adapted Material in 85 | accordance with the terms and conditions of this Public License. 86 | 87 | c. BY-SA Compatible License means a license listed at 88 | creativecommons.org/compatiblelicenses, approved by Creative 89 | Commons as essentially the equivalent of this Public License. 90 | 91 | d. Copyright and Similar Rights means copyright and/or similar rights 92 | closely related to copyright including, without limitation, 93 | performance, broadcast, sound recording, and Sui Generis Database 94 | Rights, without regard to how the rights are labeled or 95 | categorized. For purposes of this Public License, the rights 96 | specified in Section 2(b)(1)-(2) are not Copyright and Similar 97 | Rights. 98 | 99 | e. Effective Technological Measures means those measures that, in the 100 | absence of proper authority, may not be circumvented under laws 101 | fulfilling obligations under Article 11 of the WIPO Copyright 102 | Treaty adopted on December 20, 1996, and/or similar international 103 | agreements. 104 | 105 | f. Exceptions and Limitations means fair use, fair dealing, and/or 106 | any other exception or limitation to Copyright and Similar Rights 107 | that applies to Your use of the Licensed Material. 108 | 109 | g. License Elements means the license attributes listed in the name 110 | of a Creative Commons Public License. The License Elements of this 111 | Public License are Attribution and ShareAlike. 112 | 113 | h. Licensed Material means the artistic or literary work, database, 114 | or other material to which the Licensor applied this Public 115 | License. 116 | 117 | i. Licensed Rights means the rights granted to You subject to the 118 | terms and conditions of this Public License, which are limited to 119 | all Copyright and Similar Rights that apply to Your use of the 120 | Licensed Material and that the Licensor has authority to license. 121 | 122 | j. Licensor means the individual(s) or entity(ies) granting rights 123 | under this Public License. 124 | 125 | k. Share means to provide material to the public by any means or 126 | process that requires permission under the Licensed Rights, such 127 | as reproduction, public display, public performance, distribution, 128 | dissemination, communication, or importation, and to make material 129 | available to the public including in ways that members of the 130 | public may access the material from a place and at a time 131 | individually chosen by them. 132 | 133 | l. Sui Generis Database Rights means rights other than copyright 134 | resulting from Directive 96/9/EC of the European Parliament and of 135 | the Council of 11 March 1996 on the legal protection of databases, 136 | as amended and/or succeeded, as well as other essentially 137 | equivalent rights anywhere in the world. 138 | 139 | m. You means the individual or entity exercising the Licensed Rights 140 | under this Public License. Your has a corresponding meaning. 141 | 142 | 143 | Section 2 -- Scope. 144 | 145 | a. License grant. 146 | 147 | 1. Subject to the terms and conditions of this Public License, 148 | the Licensor hereby grants You a worldwide, royalty-free, 149 | non-sublicensable, non-exclusive, irrevocable license to 150 | exercise the Licensed Rights in the Licensed Material to: 151 | 152 | a. reproduce and Share the Licensed Material, in whole or 153 | in part; and 154 | 155 | b. produce, reproduce, and Share Adapted Material. 156 | 157 | 2. Exceptions and Limitations. For the avoidance of doubt, where 158 | Exceptions and Limitations apply to Your use, this Public 159 | License does not apply, and You do not need to comply with 160 | its terms and conditions. 161 | 162 | 3. Term. The term of this Public License is specified in Section 163 | 6(a). 164 | 165 | 4. Media and formats; technical modifications allowed. The 166 | Licensor authorizes You to exercise the Licensed Rights in 167 | all media and formats whether now known or hereafter created, 168 | and to make technical modifications necessary to do so. The 169 | Licensor waives and/or agrees not to assert any right or 170 | authority to forbid You from making technical modifications 171 | necessary to exercise the Licensed Rights, including 172 | technical modifications necessary to circumvent Effective 173 | Technological Measures. For purposes of this Public License, 174 | simply making modifications authorized by this Section 2(a) 175 | (4) never produces Adapted Material. 176 | 177 | 5. Downstream recipients. 178 | 179 | a. Offer from the Licensor -- Licensed Material. Every 180 | recipient of the Licensed Material automatically 181 | receives an offer from the Licensor to exercise the 182 | Licensed Rights under the terms and conditions of this 183 | Public License. 184 | 185 | b. Additional offer from the Licensor -- Adapted Material. 186 | Every recipient of Adapted Material from You 187 | automatically receives an offer from the Licensor to 188 | exercise the Licensed Rights in the Adapted Material 189 | under the conditions of the Adapter's License You apply. 190 | 191 | c. No downstream restrictions. You may not offer or impose 192 | any additional or different terms or conditions on, or 193 | apply any Effective Technological Measures to, the 194 | Licensed Material if doing so restricts exercise of the 195 | Licensed Rights by any recipient of the Licensed 196 | Material. 197 | 198 | 6. No endorsement. Nothing in this Public License constitutes or 199 | may be construed as permission to assert or imply that You 200 | are, or that Your use of the Licensed Material is, connected 201 | with, or sponsored, endorsed, or granted official status by, 202 | the Licensor or others designated to receive attribution as 203 | provided in Section 3(a)(1)(A)(i). 204 | 205 | b. Other rights. 206 | 207 | 1. Moral rights, such as the right of integrity, are not 208 | licensed under this Public License, nor are publicity, 209 | privacy, and/or other similar personality rights; however, to 210 | the extent possible, the Licensor waives and/or agrees not to 211 | assert any such rights held by the Licensor to the limited 212 | extent necessary to allow You to exercise the Licensed 213 | Rights, but not otherwise. 214 | 215 | 2. Patent and trademark rights are not licensed under this 216 | Public License. 217 | 218 | 3. To the extent possible, the Licensor waives any right to 219 | collect royalties from You for the exercise of the Licensed 220 | Rights, whether directly or through a collecting society 221 | under any voluntary or waivable statutory or compulsory 222 | licensing scheme. In all other cases the Licensor expressly 223 | reserves any right to collect such royalties. 224 | 225 | 226 | Section 3 -- License Conditions. 227 | 228 | Your exercise of the Licensed Rights is expressly made subject to the 229 | following conditions. 230 | 231 | a. Attribution. 232 | 233 | 1. If You Share the Licensed Material (including in modified 234 | form), You must: 235 | 236 | a. retain the following if it is supplied by the Licensor 237 | with the Licensed Material: 238 | 239 | i. identification of the creator(s) of the Licensed 240 | Material and any others designated to receive 241 | attribution, in any reasonable manner requested by 242 | the Licensor (including by pseudonym if 243 | designated); 244 | 245 | ii. a copyright notice; 246 | 247 | iii. a notice that refers to this Public License; 248 | 249 | iv. a notice that refers to the disclaimer of 250 | warranties; 251 | 252 | v. a URI or hyperlink to the Licensed Material to the 253 | extent reasonably practicable; 254 | 255 | b. indicate if You modified the Licensed Material and 256 | retain an indication of any previous modifications; and 257 | 258 | c. indicate the Licensed Material is licensed under this 259 | Public License, and include the text of, or the URI or 260 | hyperlink to, this Public License. 261 | 262 | 2. You may satisfy the conditions in Section 3(a)(1) in any 263 | reasonable manner based on the medium, means, and context in 264 | which You Share the Licensed Material. For example, it may be 265 | reasonable to satisfy the conditions by providing a URI or 266 | hyperlink to a resource that includes the required 267 | information. 268 | 269 | 3. If requested by the Licensor, You must remove any of the 270 | information required by Section 3(a)(1)(A) to the extent 271 | reasonably practicable. 272 | 273 | b. ShareAlike. 274 | 275 | In addition to the conditions in Section 3(a), if You Share 276 | Adapted Material You produce, the following conditions also apply. 277 | 278 | 1. The Adapter's License You apply must be a Creative Commons 279 | license with the same License Elements, this version or 280 | later, or a BY-SA Compatible License. 281 | 282 | 2. You must include the text of, or the URI or hyperlink to, the 283 | Adapter's License You apply. You may satisfy this condition 284 | in any reasonable manner based on the medium, means, and 285 | context in which You Share Adapted Material. 286 | 287 | 3. You may not offer or impose any additional or different terms 288 | or conditions on, or apply any Effective Technological 289 | Measures to, Adapted Material that restrict exercise of the 290 | rights granted under the Adapter's License You apply. 291 | 292 | 293 | Section 4 -- Sui Generis Database Rights. 294 | 295 | Where the Licensed Rights include Sui Generis Database Rights that 296 | apply to Your use of the Licensed Material: 297 | 298 | a. for the avoidance of doubt, Section 2(a)(1) grants You the right 299 | to extract, reuse, reproduce, and Share all or a substantial 300 | portion of the contents of the database; 301 | 302 | b. if You include all or a substantial portion of the database 303 | contents in a database in which You have Sui Generis Database 304 | Rights, then the database in which You have Sui Generis Database 305 | Rights (but not its individual contents) is Adapted Material, 306 | 307 | including for purposes of Section 3(b); and 308 | c. You must comply with the conditions in Section 3(a) if You Share 309 | all or a substantial portion of the contents of the database. 310 | 311 | For the avoidance of doubt, this Section 4 supplements and does not 312 | replace Your obligations under this Public License where the Licensed 313 | Rights include other Copyright and Similar Rights. 314 | 315 | 316 | Section 5 -- Disclaimer of Warranties and Limitation of Liability. 317 | 318 | a. UNLESS OTHERWISE SEPARATELY UNDERTAKEN BY THE LICENSOR, TO THE 319 | EXTENT POSSIBLE, THE LICENSOR OFFERS THE LICENSED MATERIAL AS-IS 320 | AND AS-AVAILABLE, AND MAKES NO REPRESENTATIONS OR WARRANTIES OF 321 | ANY KIND CONCERNING THE LICENSED MATERIAL, WHETHER EXPRESS, 322 | IMPLIED, STATUTORY, OR OTHER. THIS INCLUDES, WITHOUT LIMITATION, 323 | WARRANTIES OF TITLE, MERCHANTABILITY, FITNESS FOR A PARTICULAR 324 | PURPOSE, NON-INFRINGEMENT, ABSENCE OF LATENT OR OTHER DEFECTS, 325 | ACCURACY, OR THE PRESENCE OR ABSENCE OF ERRORS, WHETHER OR NOT 326 | KNOWN OR DISCOVERABLE. WHERE DISCLAIMERS OF WARRANTIES ARE NOT 327 | ALLOWED IN FULL OR IN PART, THIS DISCLAIMER MAY NOT APPLY TO YOU. 328 | 329 | b. TO THE EXTENT POSSIBLE, IN NO EVENT WILL THE LICENSOR BE LIABLE 330 | TO YOU ON ANY LEGAL THEORY (INCLUDING, WITHOUT LIMITATION, 331 | NEGLIGENCE) OR OTHERWISE FOR ANY DIRECT, SPECIAL, INDIRECT, 332 | INCIDENTAL, CONSEQUENTIAL, PUNITIVE, EXEMPLARY, OR OTHER LOSSES, 333 | COSTS, EXPENSES, OR DAMAGES ARISING OUT OF THIS PUBLIC LICENSE OR 334 | USE OF THE LICENSED MATERIAL, EVEN IF THE LICENSOR HAS BEEN 335 | ADVISED OF THE POSSIBILITY OF SUCH LOSSES, COSTS, EXPENSES, OR 336 | DAMAGES. WHERE A LIMITATION OF LIABILITY IS NOT ALLOWED IN FULL OR 337 | IN PART, THIS LIMITATION MAY NOT APPLY TO YOU. 338 | 339 | c. The disclaimer of warranties and limitation of liability provided 340 | above shall be interpreted in a manner that, to the extent 341 | possible, most closely approximates an absolute disclaimer and 342 | waiver of all liability. 343 | 344 | 345 | Section 6 -- Term and Termination. 346 | 347 | a. This Public License applies for the term of the Copyright and 348 | Similar Rights licensed here. However, if You fail to comply with 349 | this Public License, then Your rights under this Public License 350 | terminate automatically. 351 | 352 | b. Where Your right to use the Licensed Material has terminated under 353 | Section 6(a), it reinstates: 354 | 355 | 1. automatically as of the date the violation is cured, provided 356 | it is cured within 30 days of Your discovery of the 357 | violation; or 358 | 359 | 2. upon express reinstatement by the Licensor. 360 | 361 | For the avoidance of doubt, this Section 6(b) does not affect any 362 | right the Licensor may have to seek remedies for Your violations 363 | of this Public License. 364 | 365 | c. For the avoidance of doubt, the Licensor may also offer the 366 | Licensed Material under separate terms or conditions or stop 367 | distributing the Licensed Material at any time; however, doing so 368 | will not terminate this Public License. 369 | 370 | d. Sections 1, 5, 6, 7, and 8 survive termination of this Public 371 | License. 372 | 373 | 374 | Section 7 -- Other Terms and Conditions. 375 | 376 | a. The Licensor shall not be bound by any additional or different 377 | terms or conditions communicated by You unless expressly agreed. 378 | 379 | b. Any arrangements, understandings, or agreements regarding the 380 | Licensed Material not stated herein are separate from and 381 | independent of the terms and conditions of this Public License. 382 | 383 | 384 | Section 8 -- Interpretation. 385 | 386 | a. For the avoidance of doubt, this Public License does not, and 387 | shall not be interpreted to, reduce, limit, restrict, or impose 388 | conditions on any use of the Licensed Material that could lawfully 389 | be made without permission under this Public License. 390 | 391 | b. To the extent possible, if any provision of this Public License is 392 | deemed unenforceable, it shall be automatically reformed to the 393 | minimum extent necessary to make it enforceable. If the provision 394 | cannot be reformed, it shall be severed from this Public License 395 | without affecting the enforceability of the remaining terms and 396 | conditions. 397 | 398 | c. No term or condition of this Public License will be waived and no 399 | failure to comply consented to unless expressly agreed to by the 400 | Licensor. 401 | 402 | d. Nothing in this Public License constitutes or may be interpreted 403 | as a limitation upon, or waiver of, any privileges and immunities 404 | that apply to the Licensor or You, including from the legal 405 | processes of any jurisdiction or authority. 406 | 407 | 408 | ======================================================================= 409 | 410 | Creative Commons is not a party to its public 411 | licenses. Notwithstanding, Creative Commons may elect to apply one of 412 | its public licenses to material it publishes and in those instances 413 | will be considered the “Licensor.” The text of the Creative Commons 414 | public licenses is dedicated to the public domain under the CC0 Public 415 | Domain Dedication. Except for the limited purpose of indicating that 416 | material is shared under a Creative Commons public license or as 417 | otherwise permitted by the Creative Commons policies published at 418 | creativecommons.org/policies, Creative Commons does not authorize the 419 | use of the trademark "Creative Commons" or any other trademark or logo 420 | of Creative Commons without its prior written consent including, 421 | without limitation, in connection with any unauthorized modifications 422 | to any of its public licenses or any other arrangements, 423 | understandings, or agreements concerning use of licensed material. For 424 | the avoidance of doubt, this paragraph does not form part of the 425 | public licenses. 426 | 427 | Creative Commons may be contacted at creativecommons.org. 428 | 429 | -------------------------------------------------------------------------------- /OWASP_SCVS-1.0-en.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/OWASP/Software-Component-Verification-Standard/5d9dc6de3c2bf029b160abeb7c38ed41137dc473/OWASP_SCVS-1.0-en.docx -------------------------------------------------------------------------------- /OWASP_SCVS-1.0-en.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/OWASP/Software-Component-Verification-Standard/5d9dc6de3c2bf029b160abeb7c38ed41137dc473/OWASP_SCVS-1.0-en.pdf -------------------------------------------------------------------------------- /OWASP_SCVS-1.0.csv: -------------------------------------------------------------------------------- 1 | id,text,l1,l2,l3,file 2 | 1.1,All direct and transitive components and their versions are known at completion of a build,True,True,True,0x10-V1-Inventory.md 3 | 1.2,Package managers are used to manage all third-party binary components,True,True,True,0x10-V1-Inventory.md 4 | 1.3,An accurate inventory of all third-party components is available in a machine-readable format,True,True,True,0x10-V1-Inventory.md 5 | 1.4,Software bill of materials are generated for publicly or commercially available applications,True,True,True,0x10-V1-Inventory.md 6 | 1.5,Software bill of materials are required for new procurements,False,True,True,0x10-V1-Inventory.md 7 | 1.6,Software bill of materials continuously maintained and current for all systems,False,False,True,0x10-V1-Inventory.md 8 | 1.7,"Components are uniquely identified in a consistent, machine-readable format",True,True,True,0x10-V1-Inventory.md 9 | 1.8,The component type is known throughout inventory,False,False,True,0x10-V1-Inventory.md 10 | 1.9,The component function is known throughout inventory ,False,False,True,0x10-V1-Inventory.md 11 | 1.10,Point of origin is known for all components,False,False,True,0x10-V1-Inventory.md 12 | 2.1,"A structured, machine readable software bill of materials (SBOM) format is present",True,True,True,0x11-V2-Software_Bill_of_Materials.md 13 | 2.2,SBOM creation is automated and reproducible,False,True,True,0x11-V2-Software_Bill_of_Materials.md 14 | 2.3,Each SBOM has a unique identifier,True,True,True,0x11-V2-Software_Bill_of_Materials.md 15 | 2.4,"SBOM has been signed by publisher, supplier, or certifying authority",False,True,True,0x11-V2-Software_Bill_of_Materials.md 16 | 2.5,SBOM signature verification exists,False,True,True,0x11-V2-Software_Bill_of_Materials.md 17 | 2.6,SBOM signature verification is performed,False,False,True,0x11-V2-Software_Bill_of_Materials.md 18 | 2.7,SBOM is timestamped,True,True,True,0x11-V2-Software_Bill_of_Materials.md 19 | 2.8,SBOM is analyzed for risk,True,True,True,0x11-V2-Software_Bill_of_Materials.md 20 | 2.9,SBOM contains a complete and accurate inventory of all components the SBOM describes,True,True,True,0x11-V2-Software_Bill_of_Materials.md 21 | 2.10,SBOM contains an accurate inventory of all test components for the asset or application it describes,False,True,True,0x11-V2-Software_Bill_of_Materials.md 22 | 2.11,SBOM contains metadata about the asset or software the SBOM describes,False,True,True,0x11-V2-Software_Bill_of_Materials.md 23 | 2.12,Component identifiers are derived from their native ecosystems (if applicable),True,True,True,0x11-V2-Software_Bill_of_Materials.md 24 | 2.13,"Component point of origin is identified in a consistent, machine readable format (e.g. PURL)",False,False,True,0x11-V2-Software_Bill_of_Materials.md 25 | 2.14,Components defined in SBOM have accurate license information,True,True,True,0x11-V2-Software_Bill_of_Materials.md 26 | 2.15,Components defined in SBOM have valid SPDX license ID's or expressions (if applicable),False,True,True,0x11-V2-Software_Bill_of_Materials.md 27 | 2.16,Components defined in SBOM have valid copyright statements,False,False,True,0x11-V2-Software_Bill_of_Materials.md 28 | 2.17,Components defined in SBOM which have been modified from the original have detailed provenance and pedigree information ,False,False,True,0x11-V2-Software_Bill_of_Materials.md 29 | 2.18,"Components defined in SBOM have one or more file hashes (SHA-256, SHA-512, etc)",False,False,True,0x11-V2-Software_Bill_of_Materials.md 30 | 3.1,Application uses a repeatable build,True,True,True,0x12-V3-Build_Environment.md 31 | 3.2,Documentation exists on how the application is built and instructions for repeating the build,True,True,True,0x12-V3-Build_Environment.md 32 | 3.3,Application uses a continuous integration build pipeline,True,True,True,0x12-V3-Build_Environment.md 33 | 3.4,Application build pipeline prohibits alteration of build outside of the job performing the build,False,True,True,0x12-V3-Build_Environment.md 34 | 3.5,Application build pipeline prohibits alteration of package management settings,False,True,True,0x12-V3-Build_Environment.md 35 | 3.6,Application build pipeline prohibits the execution of arbitrary code outside of the context of a jobs build script,False,True,True,0x12-V3-Build_Environment.md 36 | 3.7,Application build pipeline may only perform builds of source code maintained in version control systems,True,True,True,0x12-V3-Build_Environment.md 37 | 3.8,Application build pipeline prohibits alteration of DNS and network settings during build,False,False,True,0x12-V3-Build_Environment.md 38 | 3.9,Application build pipeline prohibits alteration of certificate trust stores,False,False,True,0x12-V3-Build_Environment.md 39 | 3.10,Application build pipeline enforces authentication and defaults to deny,False,True,True,0x12-V3-Build_Environment.md 40 | 3.11,Application build pipeline enforces authorization and defaults to deny,False,True,True,0x12-V3-Build_Environment.md 41 | 3.12,Application build pipeline requires separation of concerns for the modification of system settings,False,False,True,0x12-V3-Build_Environment.md 42 | 3.13,Application build pipeline maintains a verifiable audit log of all system changes,False,False,True,0x12-V3-Build_Environment.md 43 | 3.14,Application build pipeline maintains a verifiable audit log of all build job changes,False,False,True,0x12-V3-Build_Environment.md 44 | 3.15,"Application build pipeline has required maintenance cadence where the entire stack is updated, patched, and re-certified for use",False,True,True,0x12-V3-Build_Environment.md 45 | 3.16,"Compilers, version control clients, development utilities, and software development kits are analyzed and monitored for tampering, trojans, or malicious code",False,False,True,0x12-V3-Build_Environment.md 46 | 3.17,All build-time manipulations to source or binaries are known and well defined,True,True,True,0x12-V3-Build_Environment.md 47 | 3.18,Checksums of all first-party and third-party components are documented for every build,True,True,True,0x12-V3-Build_Environment.md 48 | 3.19,Checksums of all components are accessible and delivered out-of-band whenever those components are packaged or distributed,False,True,True,0x12-V3-Build_Environment.md 49 | 3.20,Unused direct and transitive components have been identified,False,False,True,0x12-V3-Build_Environment.md 50 | 3.21,Unused direct and transitive components have been removed from the application,False,False,True,0x12-V3-Build_Environment.md 51 | 4.1,Binary components are retrieved from a package repository,True,True,True,0x13-V4-Package_Management.md 52 | 4.2,Package repository contents are congruent to an authoritative point of origin for open source components,True,True,True,0x13-V4-Package_Management.md 53 | 4.3,Package repository requires strong authentication,False,True,True,0x13-V4-Package_Management.md 54 | 4.4,Package repository supports multi-factor authentication component publishing,False,True,True,0x13-V4-Package_Management.md 55 | 4.5,Package repository components have been published with multi-factor authentication,False,False,True,0x13-V4-Package_Management.md 56 | 4.6,Package repository supports security incident reporting,False,True,True,0x13-V4-Package_Management.md 57 | 4.7,Package repository automates security incident reporting,False,False,True,0x13-V4-Package_Management.md 58 | 4.8,Package repository notifies publishers of security issues,False,True,True,0x13-V4-Package_Management.md 59 | 4.9,Package repository notifies users of security issues,False,False,True,0x13-V4-Package_Management.md 60 | 4.10,Package repository provides a verifiable way of correlating component versions to specific source codes in version control,False,True,True,0x13-V4-Package_Management.md 61 | 4.11,Package repository provides auditability when components are updated,True,True,True,0x13-V4-Package_Management.md 62 | 4.12,Package repository requires code signing to publish packages to production repositories,False,True,True,0x13-V4-Package_Management.md 63 | 4.13,Package manager verifies the integrity of packages when they are retrieved from remote repository,True,True,True,0x13-V4-Package_Management.md 64 | 4.14,Package manager verifies the integrity of packages when they are retrieved from file system,True,True,True,0x13-V4-Package_Management.md 65 | 4.15,Package repository enforces use of TLS for all interactions,True,True,True,0x13-V4-Package_Management.md 66 | 4.16,Package manager validates TLS certificate chain to repository and fails securely when validation fails,True,True,True,0x13-V4-Package_Management.md 67 | 4.17,Package repository requires and/or performs static code analysis prior to publishing a component and makes results available for others to consume,False,False,True,0x13-V4-Package_Management.md 68 | 4.18,Package manager does not execute component code,True,True,True,0x13-V4-Package_Management.md 69 | 4.19,Package manager documents package installation in machine-readable form,True,True,True,0x13-V4-Package_Management.md 70 | 5.1,Component can be analyzed with linters and/or static analysis tools,True,True,True,0x14-V5-Component_Analysis.md 71 | 5.2,Component is analyzed using linters and/or static analysis tools prior to use,False,True,True,0x14-V5-Component_Analysis.md 72 | 5.3,Linting and/or static analysis is performed with every upgrade of a component,False,True,True,0x14-V5-Component_Analysis.md 73 | 5.4,An automated process of identifying all publicly disclosed vulnerabilities in third-party and open source components is used,True,True,True,0x14-V5-Component_Analysis.md 74 | 5.5,An automated process of identifying confirmed dataflow exploitability is used,False,False,True,0x14-V5-Component_Analysis.md 75 | 5.6,An automated process of identifying non-specified component versions is used,True,True,True,0x14-V5-Component_Analysis.md 76 | 5.7,An automated process of identifying out-of-date components is used,True,True,True,0x14-V5-Component_Analysis.md 77 | 5.8,An automated process of identifying end-of-life / end-of-support components is used,False,False,True,0x14-V5-Component_Analysis.md 78 | 5.9,An automated process of identifying component type is used,False,True,True,0x14-V5-Component_Analysis.md 79 | 5.10,An automated process of identifying component function is used,False,False,True,0x14-V5-Component_Analysis.md 80 | 5.11,An automated process of identifying component quantity is used,True,True,True,0x14-V5-Component_Analysis.md 81 | 5.12,An automated process of identifying component license is used,True,True,True,0x14-V5-Component_Analysis.md 82 | 6.1,Point of origin is verifiable for source code and binary components,False,True,True,0x15-V6-Pedigree_and_Provenance.md 83 | 6.2,Chain of custody if auditable for source code and binary components,False,False,True,0x15-V6-Pedigree_and_Provenance.md 84 | 6.3,Provenance of modified components is known and documented,True,True,True,0x15-V6-Pedigree_and_Provenance.md 85 | 6.4,Pedigree of component modification is documented and verifiable,False,True,True,0x15-V6-Pedigree_and_Provenance.md 86 | 6.5,Modified components are uniquely identified and distinct from origin component,False,True,True,0x15-V6-Pedigree_and_Provenance.md 87 | 6.6,Modified components are analyzed with the same level of precision as unmodified components,True,True,True,0x15-V6-Pedigree_and_Provenance.md 88 | 6.7,Risk unique to modified components can be analyzed and associated specifically to modified variant,True,True,True,0x15-V6-Pedigree_and_Provenance.md 89 | 90 | -------------------------------------------------------------------------------- /OWASP_SCVS-1.0.json: -------------------------------------------------------------------------------- 1 | [{"id": "1.1", "text": "All direct and transitive components and their versions are known at completion of a build", "l1": true, "l2": true, "l3": true, "file": "0x10-V1-Inventory.md"}, {"id": "1.2", "text": "Package managers are used to manage all third-party binary components", "l1": true, "l2": true, "l3": true, "file": "0x10-V1-Inventory.md"}, {"id": "1.3", "text": "An accurate inventory of all third-party components is available in a machine-readable format", "l1": true, "l2": true, "l3": true, "file": "0x10-V1-Inventory.md"}, {"id": "1.4", "text": "Software bill of materials are generated for publicly or commercially available applications", "l1": true, "l2": true, "l3": true, "file": "0x10-V1-Inventory.md"}, {"id": "1.5", "text": "Software bill of materials are required for new procurements", "l1": false, "l2": true, "l3": true, "file": "0x10-V1-Inventory.md"}, {"id": "1.6", "text": "Software bill of materials continuously maintained and current for all systems", "l1": false, "l2": false, "l3": true, "file": "0x10-V1-Inventory.md"}, {"id": "1.7", "text": "Components are uniquely identified in a consistent, machine-readable format", "l1": true, "l2": true, "l3": true, "file": "0x10-V1-Inventory.md"}, {"id": "1.8", "text": "The component type is known throughout inventory", "l1": false, "l2": false, "l3": true, "file": "0x10-V1-Inventory.md"}, {"id": "1.9", "text": "The component function is known throughout inventory ", "l1": false, "l2": false, "l3": true, "file": "0x10-V1-Inventory.md"}, {"id": "1.10", "text": "Point of origin is known for all components", "l1": false, "l2": false, "l3": true, "file": "0x10-V1-Inventory.md"}, {"id": "2.1", "text": "A structured, machine readable software bill of materials (SBOM) format is present", "l1": true, "l2": true, "l3": true, "file": "0x11-V2-Software_Bill_of_Materials.md"}, {"id": "2.2", "text": "SBOM creation is automated and reproducible", "l1": false, "l2": true, "l3": true, "file": "0x11-V2-Software_Bill_of_Materials.md"}, {"id": "2.3", "text": "Each SBOM has a unique identifier", "l1": true, "l2": true, "l3": true, "file": "0x11-V2-Software_Bill_of_Materials.md"}, {"id": "2.4", "text": "SBOM has been signed by publisher, supplier, or certifying authority", "l1": false, "l2": true, "l3": true, "file": "0x11-V2-Software_Bill_of_Materials.md"}, {"id": "2.5", "text": "SBOM signature verification exists", "l1": false, "l2": true, "l3": true, "file": "0x11-V2-Software_Bill_of_Materials.md"}, {"id": "2.6", "text": "SBOM signature verification is performed", "l1": false, "l2": false, "l3": true, "file": "0x11-V2-Software_Bill_of_Materials.md"}, {"id": "2.7", "text": "SBOM is timestamped", "l1": true, "l2": true, "l3": true, "file": "0x11-V2-Software_Bill_of_Materials.md"}, {"id": "2.8", "text": "SBOM is analyzed for risk", "l1": true, "l2": true, "l3": true, "file": "0x11-V2-Software_Bill_of_Materials.md"}, {"id": "2.9", "text": "SBOM contains a complete and accurate inventory of all components the SBOM describes", "l1": true, "l2": true, "l3": true, "file": "0x11-V2-Software_Bill_of_Materials.md"}, {"id": "2.10", "text": "SBOM contains an accurate inventory of all test components for the asset or application it describes", "l1": false, "l2": true, "l3": true, "file": "0x11-V2-Software_Bill_of_Materials.md"}, {"id": "2.11", "text": "SBOM contains metadata about the asset or software the SBOM describes", "l1": false, "l2": true, "l3": true, "file": "0x11-V2-Software_Bill_of_Materials.md"}, {"id": "2.12", "text": "Component identifiers are derived from their native ecosystems (if applicable)", "l1": true, "l2": true, "l3": true, "file": "0x11-V2-Software_Bill_of_Materials.md"}, {"id": "2.13", "text": "Component point of origin is identified in a consistent, machine readable format (e.g. PURL)", "l1": false, "l2": false, "l3": true, "file": "0x11-V2-Software_Bill_of_Materials.md"}, {"id": "2.14", "text": "Components defined in SBOM have accurate license information", "l1": true, "l2": true, "l3": true, "file": "0x11-V2-Software_Bill_of_Materials.md"}, {"id": "2.15", "text": "Components defined in SBOM have valid SPDX license ID's or expressions (if applicable)", "l1": false, "l2": true, "l3": true, "file": "0x11-V2-Software_Bill_of_Materials.md"}, {"id": "2.16", "text": "Components defined in SBOM have valid copyright statements", "l1": false, "l2": false, "l3": true, "file": "0x11-V2-Software_Bill_of_Materials.md"}, {"id": "2.17", "text": "Components defined in SBOM which have been modified from the original have detailed provenance and pedigree information ", "l1": false, "l2": false, "l3": true, "file": "0x11-V2-Software_Bill_of_Materials.md"}, {"id": "2.18", "text": "Components defined in SBOM have one or more file hashes (SHA-256, SHA-512, etc)", "l1": false, "l2": false, "l3": true, "file": "0x11-V2-Software_Bill_of_Materials.md"}, {"id": "3.1", "text": "Application uses a repeatable build", "l1": true, "l2": true, "l3": true, "file": "0x12-V3-Build_Environment.md"}, {"id": "3.2", "text": "Documentation exists on how the application is built and instructions for repeating the build", "l1": true, "l2": true, "l3": true, "file": "0x12-V3-Build_Environment.md"}, {"id": "3.3", "text": "Application uses a continuous integration build pipeline", "l1": true, "l2": true, "l3": true, "file": "0x12-V3-Build_Environment.md"}, {"id": "3.4", "text": "Application build pipeline prohibits alteration of build outside of the job performing the build", "l1": false, "l2": true, "l3": true, "file": "0x12-V3-Build_Environment.md"}, {"id": "3.5", "text": "Application build pipeline prohibits alteration of package management settings", "l1": false, "l2": true, "l3": true, "file": "0x12-V3-Build_Environment.md"}, {"id": "3.6", "text": "Application build pipeline prohibits the execution of arbitrary code outside of the context of a jobs build script", "l1": false, "l2": true, "l3": true, "file": "0x12-V3-Build_Environment.md"}, {"id": "3.7", "text": "Application build pipeline may only perform builds of source code maintained in version control systems", "l1": true, "l2": true, "l3": true, "file": "0x12-V3-Build_Environment.md"}, {"id": "3.8", "text": "Application build pipeline prohibits alteration of DNS and network settings during build", "l1": false, "l2": false, "l3": true, "file": "0x12-V3-Build_Environment.md"}, {"id": "3.9", "text": "Application build pipeline prohibits alteration of certificate trust stores", "l1": false, "l2": false, "l3": true, "file": "0x12-V3-Build_Environment.md"}, {"id": "3.10", "text": "Application build pipeline enforces authentication and defaults to deny", "l1": false, "l2": true, "l3": true, "file": "0x12-V3-Build_Environment.md"}, {"id": "3.11", "text": "Application build pipeline enforces authorization and defaults to deny", "l1": false, "l2": true, "l3": true, "file": "0x12-V3-Build_Environment.md"}, {"id": "3.12", "text": "Application build pipeline requires separation of concerns for the modification of system settings", "l1": false, "l2": false, "l3": true, "file": "0x12-V3-Build_Environment.md"}, {"id": "3.13", "text": "Application build pipeline maintains a verifiable audit log of all system changes", "l1": false, "l2": false, "l3": true, "file": "0x12-V3-Build_Environment.md"}, {"id": "3.14", "text": "Application build pipeline maintains a verifiable audit log of all build job changes", "l1": false, "l2": false, "l3": true, "file": "0x12-V3-Build_Environment.md"}, {"id": "3.15", "text": "Application build pipeline has required maintenance cadence where the entire stack is updated, patched, and re-certified for use", "l1": false, "l2": true, "l3": true, "file": "0x12-V3-Build_Environment.md"}, {"id": "3.16", "text": "Compilers, version control clients, development utilities, and software development kits are analyzed and monitored for tampering, trojans, or malicious code", "l1": false, "l2": false, "l3": true, "file": "0x12-V3-Build_Environment.md"}, {"id": "3.17", "text": "All build-time manipulations to source or binaries are known and well defined", "l1": true, "l2": true, "l3": true, "file": "0x12-V3-Build_Environment.md"}, {"id": "3.18", "text": "Checksums of all first-party and third-party components are documented for every build", "l1": true, "l2": true, "l3": true, "file": "0x12-V3-Build_Environment.md"}, {"id": "3.19", "text": "Checksums of all components are accessible and delivered out-of-band whenever those components are packaged or distributed", "l1": false, "l2": true, "l3": true, "file": "0x12-V3-Build_Environment.md"}, {"id": "3.20", "text": "Unused direct and transitive components have been identified", "l1": false, "l2": false, "l3": true, "file": "0x12-V3-Build_Environment.md"}, {"id": "3.21", "text": "Unused direct and transitive components have been removed from the application", "l1": false, "l2": false, "l3": true, "file": "0x12-V3-Build_Environment.md"}, {"id": "4.1", "text": "Binary components are retrieved from a package repository", "l1": true, "l2": true, "l3": true, "file": "0x13-V4-Package_Management.md"}, {"id": "4.2", "text": "Package repository contents are congruent to an authoritative point of origin for open source components", "l1": true, "l2": true, "l3": true, "file": "0x13-V4-Package_Management.md"}, {"id": "4.3", "text": "Package repository requires strong authentication", "l1": false, "l2": true, "l3": true, "file": "0x13-V4-Package_Management.md"}, {"id": "4.4", "text": "Package repository supports multi-factor authentication component publishing", "l1": false, "l2": true, "l3": true, "file": "0x13-V4-Package_Management.md"}, {"id": "4.5", "text": "Package repository components have been published with multi-factor authentication", "l1": false, "l2": false, "l3": true, "file": "0x13-V4-Package_Management.md"}, {"id": "4.6", "text": "Package repository supports security incident reporting", "l1": false, "l2": true, "l3": true, "file": "0x13-V4-Package_Management.md"}, {"id": "4.7", "text": "Package repository automates security incident reporting", "l1": false, "l2": false, "l3": true, "file": "0x13-V4-Package_Management.md"}, {"id": "4.8", "text": "Package repository notifies publishers of security issues", "l1": false, "l2": true, "l3": true, "file": "0x13-V4-Package_Management.md"}, {"id": "4.9", "text": "Package repository notifies users of security issues", "l1": false, "l2": false, "l3": true, "file": "0x13-V4-Package_Management.md"}, {"id": "4.10", "text": "Package repository provides a verifiable way of correlating component versions to specific source codes in version control", "l1": false, "l2": true, "l3": true, "file": "0x13-V4-Package_Management.md"}, {"id": "4.11", "text": "Package repository provides auditability when components are updated", "l1": true, "l2": true, "l3": true, "file": "0x13-V4-Package_Management.md"}, {"id": "4.12", "text": "Package repository requires code signing to publish packages to production repositories", "l1": false, "l2": true, "l3": true, "file": "0x13-V4-Package_Management.md"}, {"id": "4.13", "text": "Package manager verifies the integrity of packages when they are retrieved from remote repository", "l1": true, "l2": true, "l3": true, "file": "0x13-V4-Package_Management.md"}, {"id": "4.14", "text": "Package manager verifies the integrity of packages when they are retrieved from file system", "l1": true, "l2": true, "l3": true, "file": "0x13-V4-Package_Management.md"}, {"id": "4.15", "text": "Package repository enforces use of TLS for all interactions", "l1": true, "l2": true, "l3": true, "file": "0x13-V4-Package_Management.md"}, {"id": "4.16", "text": "Package manager validates TLS certificate chain to repository and fails securely when validation fails", "l1": true, "l2": true, "l3": true, "file": "0x13-V4-Package_Management.md"}, {"id": "4.17", "text": "Package repository requires and/or performs static code analysis prior to publishing a component and makes results available for others to consume", "l1": false, "l2": false, "l3": true, "file": "0x13-V4-Package_Management.md"}, {"id": "4.18", "text": "Package manager does not execute component code", "l1": true, "l2": true, "l3": true, "file": "0x13-V4-Package_Management.md"}, {"id": "4.19", "text": "Package manager documents package installation in machine-readable form", "l1": true, "l2": true, "l3": true, "file": "0x13-V4-Package_Management.md"}, {"id": "5.1", "text": "Component can be analyzed with linters and/or static analysis tools", "l1": true, "l2": true, "l3": true, "file": "0x14-V5-Component_Analysis.md"}, {"id": "5.2", "text": "Component is analyzed using linters and/or static analysis tools prior to use", "l1": false, "l2": true, "l3": true, "file": "0x14-V5-Component_Analysis.md"}, {"id": "5.3", "text": "Linting and/or static analysis is performed with every upgrade of a component", "l1": false, "l2": true, "l3": true, "file": "0x14-V5-Component_Analysis.md"}, {"id": "5.4", "text": "An automated process of identifying all publicly disclosed vulnerabilities in third-party and open source components is used", "l1": true, "l2": true, "l3": true, "file": "0x14-V5-Component_Analysis.md"}, {"id": "5.5", "text": "An automated process of identifying confirmed dataflow exploitability is used", "l1": false, "l2": false, "l3": true, "file": "0x14-V5-Component_Analysis.md"}, {"id": "5.6", "text": "An automated process of identifying non-specified component versions is used", "l1": true, "l2": true, "l3": true, "file": "0x14-V5-Component_Analysis.md"}, {"id": "5.7", "text": "An automated process of identifying out-of-date components is used", "l1": true, "l2": true, "l3": true, "file": "0x14-V5-Component_Analysis.md"}, {"id": "5.8", "text": "An automated process of identifying end-of-life / end-of-support components is used", "l1": false, "l2": false, "l3": true, "file": "0x14-V5-Component_Analysis.md"}, {"id": "5.9", "text": "An automated process of identifying component type is used", "l1": false, "l2": true, "l3": true, "file": "0x14-V5-Component_Analysis.md"}, {"id": "5.10", "text": "An automated process of identifying component function is used", "l1": false, "l2": false, "l3": true, "file": "0x14-V5-Component_Analysis.md"}, {"id": "5.11", "text": "An automated process of identifying component quantity is used", "l1": true, "l2": true, "l3": true, "file": "0x14-V5-Component_Analysis.md"}, {"id": "5.12", "text": "An automated process of identifying component license is used", "l1": true, "l2": true, "l3": true, "file": "0x14-V5-Component_Analysis.md"}, {"id": "6.1", "text": "Point of origin is verifiable for source code and binary components", "l1": false, "l2": true, "l3": true, "file": "0x15-V6-Pedigree_and_Provenance.md"}, {"id": "6.2", "text": "Chain of custody if auditable for source code and binary components", "l1": false, "l2": false, "l3": true, "file": "0x15-V6-Pedigree_and_Provenance.md"}, {"id": "6.3", "text": "Provenance of modified components is known and documented", "l1": true, "l2": true, "l3": true, "file": "0x15-V6-Pedigree_and_Provenance.md"}, {"id": "6.4", "text": "Pedigree of component modification is documented and verifiable", "l1": false, "l2": true, "l3": true, "file": "0x15-V6-Pedigree_and_Provenance.md"}, {"id": "6.5", "text": "Modified components are uniquely identified and distinct from origin component", "l1": false, "l2": true, "l3": true, "file": "0x15-V6-Pedigree_and_Provenance.md"}, {"id": "6.6", "text": "Modified components are analyzed with the same level of precision as unmodified components", "l1": true, "l2": true, "l3": true, "file": "0x15-V6-Pedigree_and_Provenance.md"}, {"id": "6.7", "text": "Risk unique to modified components can be analyzed and associated specifically to modified variant", "l1": true, "l2": true, "l3": true, "file": "0x15-V6-Pedigree_and_Provenance.md"}] 2 | -------------------------------------------------------------------------------- /OWASP_SCVS-1.0.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | All direct and transitive components and their versions are known at completion of a build 4 | Package managers are used to manage all third-party binary components 5 | An accurate inventory of all third-party components is available in a machine-readable format 6 | Software bill of materials are generated for publicly or commercially available applications 7 | Software bill of materials are required for new procurements 8 | Software bill of materials continuously maintained and current for all systems 9 | Components are uniquely identified in a consistent, machine-readable format 10 | The component type is known throughout inventory 11 | The component function is known throughout inventory 12 | Point of origin is known for all components 13 | A structured, machine readable software bill of materials (SBOM) format is present 14 | SBOM creation is automated and reproducible 15 | Each SBOM has a unique identifier 16 | SBOM has been signed by publisher, supplier, or certifying authority 17 | SBOM signature verification exists 18 | SBOM signature verification is performed 19 | SBOM is timestamped 20 | SBOM is analyzed for risk 21 | SBOM contains a complete and accurate inventory of all components the SBOM describes 22 | SBOM contains an accurate inventory of all test components for the asset or application it describes 23 | SBOM contains metadata about the asset or software the SBOM describes 24 | Component identifiers are derived from their native ecosystems (if applicable) 25 | Component point of origin is identified in a consistent, machine readable format (e.g. PURL) 26 | Components defined in SBOM have accurate license information 27 | Components defined in SBOM have valid SPDX license ID's or expressions (if applicable) 28 | Components defined in SBOM have valid copyright statements 29 | Components defined in SBOM which have been modified from the original have detailed provenance and pedigree information 30 | Components defined in SBOM have one or more file hashes (SHA-256, SHA-512, etc) 31 | Application uses a repeatable build 32 | Documentation exists on how the application is built and instructions for repeating the build 33 | Application uses a continuous integration build pipeline 34 | Application build pipeline prohibits alteration of build outside of the job performing the build 35 | Application build pipeline prohibits alteration of package management settings 36 | Application build pipeline prohibits the execution of arbitrary code outside of the context of a jobs build script 37 | Application build pipeline may only perform builds of source code maintained in version control systems 38 | Application build pipeline prohibits alteration of DNS and network settings during build 39 | Application build pipeline prohibits alteration of certificate trust stores 40 | Application build pipeline enforces authentication and defaults to deny 41 | Application build pipeline enforces authorization and defaults to deny 42 | Application build pipeline requires separation of concerns for the modification of system settings 43 | Application build pipeline maintains a verifiable audit log of all system changes 44 | Application build pipeline maintains a verifiable audit log of all build job changes 45 | Application build pipeline has required maintenance cadence where the entire stack is updated, patched, and re-certified for use 46 | Compilers, version control clients, development utilities, and software development kits are analyzed and monitored for tampering, trojans, or malicious code 47 | All build-time manipulations to source or binaries are known and well defined 48 | Checksums of all first-party and third-party components are documented for every build 49 | Checksums of all components are accessible and delivered out-of-band whenever those components are packaged or distributed 50 | Unused direct and transitive components have been identified 51 | Unused direct and transitive components have been removed from the application 52 | Binary components are retrieved from a package repository 53 | Package repository contents are congruent to an authoritative point of origin for open source components 54 | Package repository requires strong authentication 55 | Package repository supports multi-factor authentication component publishing 56 | Package repository components have been published with multi-factor authentication 57 | Package repository supports security incident reporting 58 | Package repository automates security incident reporting 59 | Package repository notifies publishers of security issues 60 | Package repository notifies users of security issues 61 | Package repository provides a verifiable way of correlating component versions to specific source codes in version control 62 | Package repository provides auditability when components are updated 63 | Package repository requires code signing to publish packages to production repositories 64 | Package manager verifies the integrity of packages when they are retrieved from remote repository 65 | Package manager verifies the integrity of packages when they are retrieved from file system 66 | Package repository enforces use of TLS for all interactions 67 | Package manager validates TLS certificate chain to repository and fails securely when validation fails 68 | Package repository requires and/or performs static code analysis prior to publishing a component and makes results available for others to consume 69 | Package manager does not execute component code 70 | Package manager documents package installation in machine-readable form 71 | Component can be analyzed with linters and/or static analysis tools 72 | Component is analyzed using linters and/or static analysis tools prior to use 73 | Linting and/or static analysis is performed with every upgrade of a component 74 | An automated process of identifying all publicly disclosed vulnerabilities in third-party and open source components is used 75 | An automated process of identifying confirmed dataflow exploitability is used 76 | An automated process of identifying non-specified component versions is used 77 | An automated process of identifying out-of-date components is used 78 | An automated process of identifying end-of-life / end-of-support components is used 79 | An automated process of identifying component type is used 80 | An automated process of identifying component function is used 81 | An automated process of identifying component quantity is used 82 | An automated process of identifying component license is used 83 | Point of origin is verifiable for source code and binary components 84 | Chain of custody if auditable for source code and binary components 85 | Provenance of modified components is known and documented 86 | Pedigree of component modification is documented and verifiable 87 | Modified components are uniquely identified and distinct from origin component 88 | Modified components are analyzed with the same level of precision as unmodified components 89 | Risk unique to modified components can be analyzed and associated specifically to modified variant 90 | 91 | 92 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | [![Build Status](https://github.com/OWASP/Software-Component-Verification-Standard/workflows/CI%20Build/badge.svg)](https://github.com/OWASP/Software-Component-Verification-Standard/actions?workflow=CI+Build) 2 | ![GitHub](https://img.shields.io/github/license/OWASP/Software-Component-Verification-Standard) 3 | [![Slack](https://img.shields.io/badge/chat%20on-slack-46BC99.svg)](https://owasp.slack.com/messages/project-scvs) 4 | [![Twitter](https://img.shields.io/twitter/follow/owasp_scvs.svg?label=Follow&style=social)](https://twitter.com/owasp_scvs) 5 | 6 | # OWASP Software Component Verification Standard 7 | 8 | The Software Component Verification Standard (SCVS) is a community-driven effort to 9 | establish a framework for identifying activities, controls, and best practices, which can help in identifying and 10 | reducing risk in a software supply chain. 11 | 12 | Managing risk in the software supply chain is important to reduce the surface area of systems vulnerable to exploits, 13 | and to measure technical debt as a barrier to remediation. 14 | 15 | Measuring and improving software supply chain assurance is crucial for success. Organizations with supply chain visibility 16 | are better equipped to protect their brand, increase trust, reduce time-to-market, and manage costs in the event of a 17 | supply chain incident. 18 | 19 | Software supply chains involve: 20 | - technology 21 | - people 22 | - processes 23 | - institutions 24 | - and additional variables 25 | 26 | Raising the bar for supply chain assurance requires the active participation of 27 | risk managers, mission owners, and business units like legal and procurement, which have not traditionally been involved 28 | with technical implementation. 29 | 30 | Determination of risk acceptance criteria is not a problem that can be solved by enterprise tooling: it is up to risk 31 | managers and business decision makers to evaluate the advantages and trade-offs of security measures based on system 32 | exposure, regulatory requirements, and constrained financial and human resources. Mandates that are internally 33 | unachievable, or that bring development or procurement to a standstill, constitute their own security and institutional 34 | risks. 35 | 36 | SCVS is designed to be implemented incrementally, and to allow organizations to 37 | phase in controls at different levels over time. 38 | 39 | ### SCVS has the following goals: 40 | 41 | * Develop a common set of activities, controls, and best-practices that can reduce risk in a software supply chain 42 | * Identify a baseline and path to mature software supply chain vigilance 43 | -------------------------------------------------------------------------------- /cover.afdesign: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/OWASP/Software-Component-Verification-Standard/5d9dc6de3c2bf029b160abeb7c38ed41137dc473/cover.afdesign -------------------------------------------------------------------------------- /cover.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/OWASP/Software-Component-Verification-Standard/5d9dc6de3c2bf029b160abeb7c38ed41137dc473/cover.docx -------------------------------------------------------------------------------- /cover.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/OWASP/Software-Component-Verification-Standard/5d9dc6de3c2bf029b160abeb7c38ed41137dc473/cover.jpg -------------------------------------------------------------------------------- /cyclonedx.py: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env python 2 | # -*- coding: utf-8 -*- 3 | ''' CycloneDX converter class 4 | 5 | Converts the SCVS into CycloneDX Standards format 6 | Copyright (c) 2023 OWASP Foundation 7 | 8 | Permission is hereby granted, free of charge, to any person obtaining a copy 9 | of this software and associated documentation files (the "Software"), to deal 10 | in the Software without restriction, including without limitation the rights 11 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 12 | copies of the Software, and to permit persons to whom the Software is 13 | furnished to do so, subject to the following conditions: 14 | 15 | The above copyright notice and this permission notice shall be included in all 16 | copies or substantial portions of the Software. 17 | 18 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 19 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 20 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 21 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 22 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 23 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 24 | SOFTWARE. 25 | 26 | ''' 27 | 28 | import json 29 | import datetime 30 | import uuid 31 | try: 32 | from StringIO import StringIO 33 | except ImportError: 34 | from io import StringIO 35 | 36 | 37 | class CycloneDX: 38 | bom = {} 39 | bom['bomFormat'] = "CycloneDX" 40 | bom['specVersion'] = "1.6" 41 | bom['serialNumber'] = "urn:uuid:" + str(uuid.uuid4()) 42 | bom['version'] = 1 43 | bom['metadata'] = {} 44 | bom['metadata']['timestamp'] = datetime.datetime.now().astimezone().replace(microsecond=0).isoformat() 45 | bom['metadata']['licenses'] = [] 46 | bom['metadata']['licenses'].append({}) 47 | bom['metadata']['licenses'][0]['license'] = {} 48 | bom['metadata']['licenses'][0]['license']['id'] = "CC-BY-SA-4.0" 49 | bom['metadata']['licenses'][0]['license']['url'] = "https://creativecommons.org/licenses/by-sa/4.0/legalcode.txt" 50 | bom['metadata']['supplier'] = {} 51 | bom['metadata']['supplier']['name'] = "OWASP Foundation" 52 | bom['metadata']['supplier']['url'] = [ "https://owasp.org" ] 53 | bom['definitions'] = {} 54 | bom['definitions']['standards'] = [] 55 | bom['definitions']['standards'].append({}) 56 | 57 | def __init__(self, scvs_model_in): 58 | scvs = scvs_model_in 59 | bom_ref = "SCVS-" + scvs["version"] 60 | self.bom['definitions']['standards'][0]['bom-ref'] = bom_ref 61 | self.bom['definitions']['standards'][0]['name'] = "Software Component Verification Standard (SCVS)" 62 | self.bom['definitions']['standards'][0]['version'] = scvs["version"] 63 | self.bom['definitions']['standards'][0]['description'] = scvs["description"] 64 | self.bom['definitions']['standards'][0]['owner'] = "OWASP Software Component Verification Standard Project" 65 | 66 | requirements = [] 67 | l1_requirements = [] 68 | l2_requirements = [] 69 | l3_requirements = [] 70 | for scvs_domain in scvs['domains']: 71 | domain_req = self.convert_domain(scvs_domain, None) 72 | requirements.append(domain_req) 73 | if 'requirements' in scvs_domain: 74 | for scvs_requirement in scvs_domain['requirements']: 75 | requirement = self.convert_requirement(scvs_requirement, domain_req['bom-ref']) 76 | requirements.append(requirement) 77 | if 'l1' in scvs_requirement and scvs_requirement['l1'] is True: 78 | l1_requirements.append(requirement['bom-ref']) 79 | if 'l2' in scvs_requirement and scvs_requirement['l2'] is True: 80 | l2_requirements.append(requirement['bom-ref']) 81 | if 'l3' in scvs_requirement and scvs_requirement['l3'] is True: 82 | l3_requirements.append(requirement['bom-ref']) 83 | 84 | self.bom['definitions']['standards'][0]['requirements'] = requirements 85 | 86 | self.bom['definitions']['standards'][0]['levels'] = [] 87 | self.bom['definitions']['standards'][0]['levels'].append({}) 88 | self.bom['definitions']['standards'][0]['levels'][0] = {} 89 | self.bom['definitions']['standards'][0]['levels'][0]['bom-ref'] = "level-1" 90 | self.bom['definitions']['standards'][0]['levels'][0]['identifier'] = "Level 1" 91 | self.bom['definitions']['standards'][0]['levels'][0]['description'] = "SCVS level 1 lays the groundwork from which to build upon." 92 | self.bom['definitions']['standards'][0]['levels'][0]['requirements'] = l1_requirements 93 | self.bom['definitions']['standards'][0]['levels'].append({}) 94 | self.bom['definitions']['standards'][0]['levels'][1] = {} 95 | self.bom['definitions']['standards'][0]['levels'][1]['bom-ref'] = "level-2" 96 | self.bom['definitions']['standards'][0]['levels'][1]['identifier'] = "Level 2" 97 | self.bom['definitions']['standards'][0]['levels'][1]['description'] = "SCVS level 2 expands the breadth of level 1 capabilities. Level 2 is appropriate for software intensive enterprises and organizations with existing risk management frameworks and regulatory and/or contractual requirements. Level 2 also expands the number of stakeholders including those with non-technical roles. Adoption of level 2 may require additional resources and domain expertise to achieve." 98 | self.bom['definitions']['standards'][0]['levels'][1]['requirements'] = l2_requirements 99 | self.bom['definitions']['standards'][0]['levels'].append({}) 100 | self.bom['definitions']['standards'][0]['levels'][2] = {} 101 | self.bom['definitions']['standards'][0]['levels'][2]['bom-ref'] = "level-3" 102 | self.bom['definitions']['standards'][0]['levels'][2]['identifier'] = "Level 3" 103 | self.bom['definitions']['standards'][0]['levels'][2]['description'] = "SCVS level 3 extends the depth of level 2 capabilities. Level 3 is applicable in critical infrastructure and systems with safety requirements. Auditability and end-to-end transparency in the supply chain is required to maintain a high security posture in these systems and the organizations that produce and maintain them." 104 | self.bom['definitions']['standards'][0]['levels'][2]['requirements'] = l3_requirements 105 | 106 | self.bom['definitions']['standards'][0]['externalReferences'] = [] 107 | self.bom['definitions']['standards'][0]['externalReferences'].append({}) 108 | self.bom['definitions']['standards'][0]['externalReferences'][0]['type'] = 'website' 109 | self.bom['definitions']['standards'][0]['externalReferences'][0]['url'] = 'https://owasp.org/scvs' 110 | self.bom['definitions']['standards'][0]['externalReferences'].append({}) 111 | self.bom['definitions']['standards'][0]['externalReferences'][1]['type'] = 'website' 112 | self.bom['definitions']['standards'][0]['externalReferences'][1]['url'] = 'https://scvs.owasp.org' 113 | self.bom['definitions']['standards'][0]['externalReferences'].append({}) 114 | self.bom['definitions']['standards'][0]['externalReferences'][2]['type'] = 'vcs' 115 | self.bom['definitions']['standards'][0]['externalReferences'][2]['url'] = 'https://github.com/OWASP/Software-Component-Verification-Standard' 116 | self.bom['definitions']['standards'][0]['externalReferences'].append({}) 117 | self.bom['definitions']['standards'][0]['externalReferences'][3]['type'] = 'issue-tracker' 118 | self.bom['definitions']['standards'][0]['externalReferences'][3]['url'] = 'https://github.com/OWASP/Software-Component-Verification-Standard/issues' 119 | self.bom['definitions']['standards'][0]['externalReferences'].append({}) 120 | self.bom['definitions']['standards'][0]['externalReferences'][4]['type'] = 'social' 121 | self.bom['definitions']['standards'][0]['externalReferences'][4]['url'] = 'https://twitter.com/OWASP_SCVS' 122 | 123 | def convert_domain(self, scvs_requirement, parent): 124 | requirement = {} 125 | requirement['bom-ref'] = scvs_requirement['shortcode'] 126 | requirement['identifier'] = scvs_requirement['shortcode'] 127 | if 'name' in scvs_requirement and scvs_requirement['name'] != '': 128 | requirement['title'] = scvs_requirement['name'] 129 | if 'objective' in scvs_requirement and scvs_requirement['objective'] != '': 130 | requirement['text'] = scvs_requirement['objective'] 131 | if parent: 132 | requirement['parent'] = parent 133 | return requirement 134 | 135 | def convert_requirement(self, scvs_requirement, parent): 136 | requirement = {} 137 | requirement['bom-ref'] = scvs_requirement['id'] 138 | requirement['identifier'] = scvs_requirement['id'] 139 | if 'text' in scvs_requirement and scvs_requirement['text'] != '': 140 | requirement['text'] = scvs_requirement['text'] 141 | if parent: 142 | requirement['parent'] = parent 143 | return requirement 144 | 145 | def to_json(self): 146 | ''' Returns a JSON-formatted string ''' 147 | return json.dumps(self.bom, indent = 2, sort_keys = False, ensure_ascii=False).strip() 148 | -------------------------------------------------------------------------------- /en/0x00-Header.md: -------------------------------------------------------------------------------- 1 | # 2 | 3 | ![OWASP LOGO](./images/owasp_logo_1c_notext.png) 4 | 5 | # Software Component Verification Standard 6 | 7 | ## SNAPSHOT 8 | 9 |
10 | \newpage 11 |
12 | -------------------------------------------------------------------------------- /en/0x01-Frontispiece.md: -------------------------------------------------------------------------------- 1 | # Frontispiece 2 | 3 | ## About the Standard 4 | 5 | The Software Component Verification Standard is a grouping of controls, separated by control family, which can be used by architects, developers, security, legal, and compliance to define, build, and verify the integrity of their software supply chain. 6 | 7 | ## Copyright and License 8 | 9 | ![license](./images/license.png) 10 | 11 | Copyright © 2020 The OWASP Foundation. 12 | 13 | This document is released under the [Creative Commons Attribution ShareAlike 4.0 license](https://creativecommons.org/licenses/by-sa/4.0/). For any reuse or distribution, you must make clear to others the license terms of this work. 14 | 15 | Version 1.0, 25 June 2020 16 | 17 | ## Project Leads 18 | 19 | - Steve Springett 20 | 21 | ## Contributors and Reviewers 22 | 23 | - Dave Russo 24 | - Garret Fick 25 | - JC Herz 26 | - John Scott 27 | - Mark Symons 28 | - Pruthvi Nallapareddy 29 | - Bryan Garcia 30 | 31 | The Software Component Verification Standard is built upon the shoulders of those involved. The project is inspired by the OWASP Application Security Verification Standard and the work of their contributors. 32 | 33 | If a credit is missing from the credit list above, please contact steve.springett@owasp.org or log a ticket at GitHub to be recognized in future updates. 34 | 35 |
36 | \newpage 37 |
38 | -------------------------------------------------------------------------------- /en/0x02-Preface.md: -------------------------------------------------------------------------------- 1 | # Preface 2 | 3 | Welcome to the Software Component Verification Standard (SCVS) version 1.0. The SCVS is a community-driven effort to 4 | establish a framework for identifying activities, controls, and best practices, which can help in identifying and 5 | reducing risk in a software supply chain. 6 | 7 | Managing risk in the software supply chain is important to reduce the surface area of systems vulnerable to exploits, 8 | and to measure technical debt as a barrier to remediation. 9 | 10 | Measuring and improving software supply chain assurance is crucial for success. Organizations with supply chain visibility 11 | are better equipped to protect their brand, increase trust, reduce time-to-market, and manage costs in the event of a 12 | supply chain incident. 13 | 14 | Software supply chains involve: 15 | - technology 16 | - people 17 | - processes 18 | - institutions 19 | - and additional variables 20 | 21 | Raising the bar for supply chain assurance requires the active participation of 22 | risk managers, mission owners, and business units like legal and procurement, which have not traditionally been involved 23 | with technical implementation. 24 | 25 | Determination of risk acceptance criteria is not a problem that can be solved by enterprise tooling: it is up to risk 26 | managers and business decision makers to evaluate the advantages and trade-offs of security measures based on system 27 | exposure, regulatory requirements, and constrained financial and human resources. Mandates that are internally 28 | unachievable, or that bring development or procurement to a standstill, constitute their own security and institutional 29 | risks. 30 | 31 | SCVS is designed to be implemented incrementally, and to allow organizations to 32 | phase in controls at different levels over time. 33 | 34 |
35 | \newpage 36 |
37 | -------------------------------------------------------------------------------- /en/0x03-Using-SCVS.md: -------------------------------------------------------------------------------- 1 | # Using the SCVS 2 | 3 | SCVS has the following goals: 4 | 5 | * Develop a common set of activities, controls, and best-practices that can reduce risk in a software supply chain 6 | * Identify a baseline and path to mature software supply chain vigilance 7 | 8 | ## Control Families 9 | There are six control families that contain multiple controls that apply to different aspects of component verification 10 | or processes where component verification occurs. The control families are: 11 | 12 | * V1: Inventory 13 | * V2: Software Bill of Materials (SBOM) 14 | * V3: Build Environment 15 | * V4: Package Management 16 | * V5: Component Analysis 17 | * V6: Pedigree and Provenance 18 | 19 | ## Software Component Verification Levels 20 | 21 | The Software Component Verification Standard defines three verification levels. Higher levels include additional controls. 22 | 23 | * SCVS Level 1 is for low-assurance requirements where basic forms of analysis would suffice. 24 | * SCVS Level 2 is for moderately sensitive software where additional analysis or due diligence is required. 25 | * SCVS Level 3 is for high-assurance requirements due to the sensitivity of data or use of the software. 26 | 27 | 28 | ### Level 1 29 | SCVS level 1 lays the groundwork from which to build upon. This level focuses on implementing best practices such as: 30 | - creating software bill of materials with complete and accurate inventory 31 | - utilizing continuous integration to produce repeatable builds 32 | - performing analysis of third-party components with tools and intelligence that are publicly available 33 | 34 | Adoption of level 1 can be achieved with modern software engineering practices. 35 | 36 | 37 | ### Level 2 38 | SCVS level 2 expands the breadth of level 1 capabilities. Level 2 is appropriate for software intensive enterprises and 39 | organizations with existing risk management frameworks and regulatory and/or contractual requirements. Level 2 also 40 | expands the number of stakeholders including those with non-technical roles. Adoption of level 2 may require 41 | additional resources and domain expertise to achieve. 42 | 43 | 44 | ### Level 3 45 | SCVS level 3 extends the depth of level 2 capabilities. Level 3 is applicable in critical infrastructure and systems 46 | with safety requirements. Auditability and end-to-end transparency in the supply chain is required to maintain a 47 | high security posture in these systems and the organizations that produce and maintain them. 48 | 49 | 50 | ## How to Use This Standard 51 | 52 | One of the best ways to use the Software Component Verification Standard is to use it as a method of assessment and a 53 | way to sequence incremental improvement. Tailoring the SCVS to your use cases will increase the focus on the security 54 | requirements that are most important to your organization. Organizations may choose to adopt certain controls from higher 55 | levels without implementing all higher-level controls. 56 | 57 | One use case for the SCVS is to assess internal software development processes and capabilities. Another is to evaluate 58 | suppliers, which can include open source software maintainers, contract software developers, and commercial software 59 | vendors. 60 | 61 | ### Assessing First Party Capabilities 62 | SCVS provides a structured method to assess and qualify internal software capabilities and processes, and to identify 63 | areas where verifiability can be improved. Because of the tiered and topical structure of SCVS, the same organization 64 | can be at different levels within or across categories of verification. Depending on required levels of assurance for a 65 | given system, different levels of SCVS controls may be required for system approval. 66 | 67 | SCVS controls are formulated to be automatable, and to provide the basis for system approval on a continuous basis. 68 | Given the rate of change in software composition, especially for capabilities developed in a continuous integration 69 | pipeline, continuity of assurance requires continuous rather than one-time verification. 70 | 71 | ### Evaluating Suppliers 72 | SCVS provides a standardized way to assess supply chain transparency provided by contract or outsourced software 73 | suppliers, based on the documentation and metadata present in the supplier's software development workflow and/or 74 | provided with software deliverables. Specifically, the provision of a software bill of materials (SBOM) can be 75 | requested or required by software customers to establish supply chain visibility and differentiate suppliers. 76 | 77 | Because of the tiered and topical structure of SCVS, it can be used for analysis of alternatives and/or used in whole 78 | or in part to evaluate proposals for procurement. SCVS controls at different levels can be used to qualify 79 | eligibility for procurement, or as an element of scoring proposals. 80 | 81 | Supplier provision of software bills of materials and other verification data allows customers to monitor risks present 82 | in supplier software on an ongoing basis to achieve visibility regardless of supplier-provided notification or updates. 83 | The auditability of this data enables formulation and enforcement of contractual provisions to remediate known 84 | vulnerabilities within a specified time period. 85 | 86 | ## Applying SCVS 87 | 88 | The Software Component Verification Standard places emphasis on controls that can be implemented or verified 89 | through automation. The control families are not specific to a single development team. They represent 90 | stakeholders across an organization, including software developers, security and risk managers, and procurement 91 | departments. Active participation of all stakeholders is necessary to measure and improve cyber posture. 92 | Once an organization has determined the current maturity baseline, it can determine goals and timelines to improve maturity 93 | and devise methods for which the controls can be implemented or verified through automation. 94 | 95 | Satisfying control requirements at a higher SCVS level may be more dependent on business process than available technical methods. 96 | 97 |
98 | \newpage 99 |
100 | -------------------------------------------------------------------------------- /en/0x04-Assessment_and_Certification.md: -------------------------------------------------------------------------------- 1 | # Assessment and Certification 2 | 3 | ## OWASP's Stance on SCVS Certifications and Trust Marks 4 | 5 | OWASP, as a vendor-neutral not-for-profit organization, does not certify any vendors, verifiers or software. 6 | 7 | All such assurance assertions, trust marks, or certifications are not officially vetted, registered, or certified by 8 | OWASP, so an organization relying upon such a view needs to be cautious of the trust placed in any third-party or 9 | trust mark claiming SCVS certification. 10 | 11 | This should not inhibit organizations from offering such assurance services, as long as they do not claim official 12 | OWASP certification. 13 | 14 | ## Guidance for Certifying Software Component Supply Chains 15 | 16 | The recommended way of verifying compliance of a software supply chain with SCVS is by performing an "open book" 17 | review, meaning that the auditors are granted access to key resources such as legal, procurement, build engineers, 18 | developers, repositories, documentation, and build environments with source code. 19 | 20 | A certifying organization must include in any report the scope of the verification (particularly if any practice is out 21 | of scope), a summary of verification findings, with clear indications of how to resolve and improve results. In case of 22 | dispute, there should be sufficient supportive evidence to demonstrate that every verified practice has indeed been met. 23 | 24 | Evaluators and software suppliers may describe assessments as having been performed using SCVS controls, as long as 25 | control levels are disclosed. 26 | 27 | ### The Role of Automated Verification 28 | 29 | Whenever possible, automation should be used to verify the controls detailed in SCVS in order to increase efficiency 30 | and accuracy. Some controls cannot be verified through automation. However, for the controls that can, automation 31 | is encouraged if the results can be validated through other means. 32 | 33 | For higher levels of assurance controls may be independently validated using automated methods. 34 | 35 |
36 | \newpage 37 |
38 | -------------------------------------------------------------------------------- /en/0x10-V1-Inventory.md: -------------------------------------------------------------------------------- 1 | # V1: Inventory Requirements 2 | 3 | ## Control Objective 4 | 5 | An accurate inventory of all components used in the creation of software is a foundational requirement for further 6 | analysis. The following controls incorporate single application inventories, organizational inventories, and approaches 7 | to enable software transparency when procuring new software or systems. 8 | 9 | Component identification varies based on the ecosystem the component is part of. Therefore, for all inventory 10 | purposes, the use of identifiers, such as Package URL, may be used to standardize and normalize naming conventions for 11 | managed dependencies. 12 | 13 | An organization-wide inventory of all first-party and third-party (including open source) components allows for greater 14 | transparency within the organization, promotes software standardization and reuse, and allows for rapid impact analysis. 15 | 16 | ## Verification Requirements 17 | 18 | | # | Description | L1 | L2 | L3 | 19 | | :---: | :--- | :---: | :---: | :---: | 20 | | **1.1** | All direct and transitive components and their versions are known at completion of a build | ✓ | ✓ | ✓ | 21 | | **1.2** | Package managers are used to manage all third-party binary components | ✓ | ✓ | ✓ | 22 | | **1.3** | An accurate inventory of all third-party components is available in a machine-readable format | ✓ | ✓ | ✓ | 23 | | **1.4** | Software bill of materials are generated for publicly or commercially available applications | ✓ | ✓ | ✓ | 24 | | **1.5** | Software bill of materials are required for new procurements | | ✓ | ✓ | 25 | | **1.6** | Software bill of materials continuously maintained and current for all systems | | | ✓ | 26 | | **1.7** | Components are uniquely identified in a consistent, machine-readable format | ✓ | ✓ | ✓ | 27 | | **1.8** | The component type is known throughout inventory | | | ✓ | 28 | | **1.9** | The component function is known throughout inventory | | | ✓ | 29 | | **1.10** | Point of origin is known for all components | | | ✓ | 30 | -------------------------------------------------------------------------------- /en/0x11-V2-Software_Bill_of_Materials.md: -------------------------------------------------------------------------------- 1 | # V2: Software Bill of Materials (SBOM) Requirements 2 | 3 | ## Control Objective 4 | 5 | Automatically creating accurate Software Bill of Materials (SBOM) in the build pipeline is one indicator of mature 6 | development processes. SBOMs should be a machine readable format. 7 | Each format has different capabilities and use-cases they excel in. Part of SBOM adoption is identifying the use-cases 8 | and capabilities best suited to specific purposes. While SBOM format standardization across an organization may be 9 | desirable, it may be necessary to adopt more than one to meet functional, contractual, compliance, or regulatory 10 | requirements. 11 | 12 | ## Verification Requirements 13 | 14 | | # | Description | L1 | L2 | L3 | 15 | | :---: | :--- | :---: | :---: | :---: | 16 | | **2.1** | A structured, machine readable software bill of materials (SBOM) format is present | ✓ | ✓ | ✓ | 17 | | **2.2** | SBOM creation is automated and reproducible | | ✓ | ✓ | 18 | | **2.3** | Each SBOM has a unique identifier | ✓ | ✓ | ✓ | 19 | | **2.4** | SBOM has been signed by publisher, supplier, or certifying authority | | ✓ | ✓ | 20 | | **2.5** | SBOM signature verification exists | | ✓ | ✓ | 21 | | **2.6** | SBOM signature verification is performed | | | ✓ | 22 | | **2.7** | SBOM is timestamped | ✓ | ✓ | ✓ | 23 | | **2.8** | SBOM is analyzed for risk | ✓ | ✓ | ✓ | 24 | | **2.9** | SBOM contains a complete and accurate inventory of all components the SBOM describes | ✓ | ✓ | ✓ | 25 | | **2.10** | SBOM contains an accurate inventory of all test components for the asset or application it describes | | ✓ | ✓ | 26 | | **2.11** | SBOM contains metadata about the asset or software the SBOM describes | | ✓ | ✓ | 27 | | **2.12** | Component identifiers are derived from their native ecosystems (if applicable) | ✓ | ✓ | ✓ | 28 | | **2.13** | Component point of origin is identified in a consistent, machine readable format (e.g. PURL) | | | ✓ | 29 | | **2.14** | Components defined in SBOM have accurate license information | ✓ | ✓ | ✓ | 30 | | **2.15** | Components defined in SBOM have valid SPDX license ID's or expressions (if applicable) | | ✓ | ✓ | 31 | | **2.16** | Components defined in SBOM have valid copyright statements | | | ✓ | 32 | | **2.17** | Components defined in SBOM which have been modified from the original have detailed provenance and pedigree information | | | ✓ | 33 | | **2.18** | Components defined in SBOM have one or more file hashes (SHA-256, SHA-512, etc) | | | ✓ | 34 | -------------------------------------------------------------------------------- /en/0x12-V3-Build_Environment.md: -------------------------------------------------------------------------------- 1 | # V3: Build Environment Requirements 2 | 3 | ## Control Objective 4 | 5 | Software build pipelines may consist of source code repositories, package repositories, continuous integration and 6 | delivery processes, and test procedures, along with the network infrastructure and services that enable these 7 | capabilities. Every system in the pipeline may provide an entry-point in which flaws, failures, and misconfigurations 8 | can compromise the software supply chain. Hardening the systems involved and implementing best practices reduces the 9 | likelihood of compromise. 10 | 11 | ## Verification Requirements 12 | 13 | | # | Description | L1 | L2 | L3 | 14 | | :---: | :--- | :---: | :---: | :---: | 15 | | **3.1** | Application uses a repeatable build | ✓ | ✓ | ✓ | 16 | | **3.2** | Documentation exists on how the application is built and instructions for repeating the build | ✓ | ✓ | ✓ | 17 | | **3.3** | Application uses a continuous integration build pipeline | ✓ | ✓ | ✓ | 18 | | **3.4** | Application build pipeline prohibits alteration of build outside of the job performing the build | | ✓ | ✓ | 19 | | **3.5** | Application build pipeline prohibits alteration of package management settings | | ✓ | ✓ | 20 | | **3.6** | Application build pipeline prohibits the execution of arbitrary code outside of the context of a jobs build script | | ✓ | ✓ | 21 | | **3.7** | Application build pipeline may only perform builds of source code maintained in version control systems | ✓ | ✓ | ✓ | 22 | | **3.8** | Application build pipeline prohibits alteration of DNS and network settings during build | | | ✓ | 23 | | **3.9** | Application build pipeline prohibits alteration of certificate trust stores | | | ✓ | 24 | | **3.10** | Application build pipeline enforces authentication and defaults to deny | | ✓ | ✓ | 25 | | **3.11** | Application build pipeline enforces authorization and defaults to deny | | ✓ | ✓ | 26 | | **3.12** | Application build pipeline requires separation of concerns for the modification of system settings | | | ✓ | 27 | | **3.13** | Application build pipeline maintains a verifiable audit log of all system changes | | | ✓ | 28 | | **3.14** | Application build pipeline maintains a verifiable audit log of all build job changes | | | ✓ | 29 | | **3.15** | Application build pipeline has required maintenance cadence where the entire stack is updated, patched, and re-certified for use | | ✓ | ✓ | 30 | | **3.16** | Compilers, version control clients, development utilities, and software development kits are analyzed and monitored for tampering, trojans, or malicious code | | | ✓ | 31 | | **3.17** | All build-time manipulations to source or binaries are known and well defined | ✓ | ✓ | ✓ | 32 | | **3.18** | Checksums of all first-party and third-party components are documented for every build | ✓ | ✓ | ✓ | 33 | | **3.19** | Checksums of all components are accessible and delivered out-of-band whenever those components are packaged or distributed | | ✓ | ✓ | 34 | | **3.20** | Unused direct and transitive components have been identified | | | ✓ | 35 | | **3.21** | Unused direct and transitive components have been removed from the application | | | ✓ | 36 | -------------------------------------------------------------------------------- /en/0x13-V4-Package_Management.md: -------------------------------------------------------------------------------- 1 | # V4: Package Management Requirements 2 | 3 | ## Control Objective 4 | 5 | Open source components intended for reuse are often published to ecosystem-specific package repositories. 6 | Centralized repositories exist for many build systems including Maven, .NET, NPM and Python. Repositories 7 | internal to an organization may additionally provide reuse of first-party components as well as access to 8 | trusted third-party components. 9 | 10 | Package managers are often invoked during the build process and are responsible for resolving component versions 11 | and retrieving components from repositories. 12 | 13 | While there are tremendous business, technical, and security benefits to using package managers and centralized 14 | repositories, they are often targets for adversaries. Implementing best practices can dramatically reduce risk of 15 | compromise in the software supply chain. 16 | 17 | ## Verification Requirements 18 | 19 | | # | Description | L1 | L2 | L3 | 20 | | :---: | :--- | :---: | :---: | :---: | 21 | | **4.1** | Binary components are retrieved from a package repository | ✓ | ✓ | ✓ | 22 | | **4.2** | Package repository contents are congruent to an authoritative point of origin for open source components | ✓ | ✓ | ✓ | 23 | | **4.3** | Package repository requires strong authentication | | ✓ | ✓ | 24 | | **4.4** | Package repository supports multi-factor authentication component publishing | | ✓ | ✓ | 25 | | **4.5** | Package repository components have been published with multi-factor authentication | | | ✓ | 26 | | **4.6** | Package repository supports security incident reporting | | ✓ | ✓ | 27 | | **4.7** | Package repository automates security incident reporting | | | ✓ | 28 | | **4.8** | Package repository notifies publishers of security issues | | ✓ | ✓ | 29 | | **4.9** | Package repository notifies users of security issues | | | ✓ | 30 | | **4.10** | Package repository provides a verifiable way of correlating component versions to specific source codes in version control | | ✓ | ✓ | 31 | | **4.11** | Package repository provides auditability when components are updated | ✓ | ✓ | ✓ | 32 | | **4.12** | Package repository requires code signing to publish packages to production repositories | | ✓ | ✓ | 33 | | **4.13** | Package manager verifies the integrity of packages when they are retrieved from remote repository | ✓ | ✓ | ✓ | 34 | | **4.14** | Package manager verifies the integrity of packages when they are retrieved from file system | ✓ | ✓ | ✓ | 35 | | **4.15** | Package repository enforces use of TLS for all interactions | ✓ | ✓ | ✓ | 36 | | **4.16** | Package manager validates TLS certificate chain to repository and fails securely when validation fails | ✓ | ✓ | ✓ | 37 | | **4.17** | Package repository requires and/or performs static code analysis prior to publishing a component and makes results available for others to consume | | | ✓ | 38 | | **4.18** | Package manager does not execute component code | ✓ | ✓ | ✓ | 39 | | **4.19** | Package manager documents package installation in machine-readable form | ✓ | ✓ | ✓ | 40 | -------------------------------------------------------------------------------- /en/0x14-V5-Component_Analysis.md: -------------------------------------------------------------------------------- 1 | # V5: Component Analysis Requirements 2 | 3 | ## Control Objective 4 | 5 | Component Analysis is the process of identifying potential areas of risk from the use of third-party and open-source 6 | software components. Every component, direct or transitive, is a candidate for analysis. Risk inherited through the use 7 | of third-party software may directly affect the application or systems that rely on them. 8 | 9 | #### Known Vulnerabilities 10 | There are multiple public and commercial sources of vulnerability intelligence. Vulnerabilities become known when they 11 | are published to services such as the National Vulnerability Database (NVD), or are otherwise documented in public 12 | defect trackers, commit logs, or other public source. 13 | 14 | #### Component Version Currency 15 | If component versions are specified, then determining if a component is out-of-date or end-of-life is possible. 16 | Outdated and end-of-life components are more likely to be vulnerable and less likely to be supported as first-class 17 | entities. Out-of-date components can slow down system remediation due to interoperability issues. Using up-to-date 18 | components reduces exposure time and may include remediations of non-disclosed vulnerabilities. 19 | 20 | #### Component Type 21 | Frameworks and libraries have unique upgrade challenges and associated risk. Abstractions, coupling, and architectural 22 | design patterns may affect the risk of using a given component type. Libraries, frameworks, applications, containers, 23 | and operating systems are common component types. 24 | 25 | #### Component Function 26 | Identifying and analyzing the purpose of each component may reveal the existence of components with duplicate or 27 | similar functionality. Potential risk can be reduced by minimizing the number of components for each function and by 28 | choosing the highest quality components for each function. 29 | 30 | #### Component Quantity 31 | The operational and maintenance cost of using open source may increase with the adoption of every new component. 32 | Decreased ability to maintain growing sets of components over time can be expected. This is especially true for teams 33 | with time-boxed constraints. 34 | 35 | #### License 36 | Third-party and open-source software is typically released under one or more licenses. The chosen license may or may 37 | not allow certain types of usage, contain distribution requirements or limitations, or require specific actions if the 38 | component is modified. Utilizing components with licenses which conflict with an organizations objectives or ability 39 | can create risk to the business. 40 | 41 | ## Verification Requirements 42 | 43 | | # | Description | L1 | L2 | L3 | 44 | | :---: | :--- | :---: | :---: | :---: | 45 | | **5.1** | Component can be analyzed with linters and/or static analysis tools | ✓ | ✓ | ✓ | 46 | | **5.2** | Component is analyzed using linters and/or static analysis tools prior to use | | ✓ | ✓ | 47 | | **5.3** | Linting and/or static analysis is performed with every upgrade of a component | | ✓ | ✓ | 48 | | **5.4** | An automated process of identifying all publicly disclosed vulnerabilities in third-party and open source components is used | ✓ | ✓ | ✓ | 49 | | **5.5** | An automated process of identifying confirmed dataflow exploitability is used | | | ✓ | 50 | | **5.6** | An automated process of identifying non-specified component versions is used | ✓ | ✓ | ✓ | 51 | | **5.7** | An automated process of identifying out-of-date components is used | ✓ | ✓ | ✓ | 52 | | **5.8** | An automated process of identifying end-of-life / end-of-support components is used | | | ✓ | 53 | | **5.9** | An automated process of identifying component type is used | | ✓ | ✓ | 54 | | **5.10** | An automated process of identifying component function is used | | | ✓ | 55 | | **5.11** | An automated process of identifying component quantity is used | ✓ | ✓ | ✓ | 56 | | **5.12** | An automated process of identifying component license is used | ✓ | ✓ | ✓ | 57 | -------------------------------------------------------------------------------- /en/0x15-V6-Pedigree_and_Provenance.md: -------------------------------------------------------------------------------- 1 | # V6: Pedigree and Provenance Requirements 2 | 3 | ## Control Objective 4 | 5 | Identify point of origin and chain of custody in order to manage system risk if either point of origin or 6 | chain of custody is compromised. For internal package managers and repositories it is important to maintain 7 | pedigree and provenance data for imported components. 8 | 9 | ## Verification Requirements 10 | 11 | | # | Description | L1 | L2 | L3 | 12 | | :---: | :--- | :---: | :---: | :---: | 13 | | **6.1** | Point of origin is verifiable for source code and binary components | | ✓ | ✓ | 14 | | **6.2** | Chain of custody if auditable for source code and binary components | | | ✓ | 15 | | **6.3** | Provenance of modified components is known and documented | ✓ | ✓ | ✓ | 16 | | **6.4** | Pedigree of component modification is documented and verifiable | | ✓ | ✓ | 17 | | **6.5** | Modified components are uniquely identified and distinct from origin component | | ✓ | ✓ | 18 | | **6.6** | Modified components are analyzed with the same level of precision as unmodified components | ✓ | ✓ | ✓ | 19 | | **6.7** | Risk unique to modified components can be analyzed and associated specifically to modified variant | ✓ | ✓ | ✓ | 20 | 21 |
22 | \newpage 23 |
24 | -------------------------------------------------------------------------------- /en/0x80-Guidance-Open_Source_Policy.md: -------------------------------------------------------------------------------- 1 | # Guidance: Open Source Policy 2 | 3 | The following points should be viewed as suggestions based on the success and best practices of organizations 4 | employing them. They are not part of SCVS. 5 | 6 | - All organizations that use open source software should have an open source policy 7 | - The open source policy is supported and enforced by cross-functional stakeholders 8 | - The open source policy should address: 9 | - The age of a component based on its release or published date 10 | - How many major or minor revisions old are acceptable 11 | - Guidance for keeping components continuously updated via automation 12 | - Exclusion criteria for components with known vulnerabilities 13 | - Mean-time-to-remediate criteria for updating at-risk components 14 | - Restrictions on using components that are end-of-life or end-of-support 15 | - Criteria for supplier selection or exclusion 16 | - Usage-based list of acceptable licenses 17 | - Prohibited components list 18 | - Mechanisms and permissions for providing modifications back to the community producing the component 19 | 20 |
21 | \newpage 22 |
23 | -------------------------------------------------------------------------------- /en/0x90-Appendix-A_Glossary.md: -------------------------------------------------------------------------------- 1 | # Appendix A: Glossary 2 | 3 | - **Chain of custody** - Auditable documentation of point of origin as well as the method of transfer from point of 4 | origin to point of destination and the identity of the transfer agent. 5 | 6 | - **Component function** - The purpose for which a software component exists. Examples of component functions include 7 | parsers, database persistence, and authentication providers. 8 | 9 | - **Component type** - The general classification of a software components architecture. Examples of component types 10 | include libraries, frameworks, applications, containers, and operating systems. 11 | 12 | - **CycloneDX** - A software bill of materials specification designed to be lightweight and security-focused. 13 | 14 | - **Direct dependency** - A software component that is referenced by a program itself. 15 | 16 | - **Package manager** - A distribution mechanism that makes software artifacts discoverable by requesters. 17 | 18 | - **Package URL (PURL)** - An ecosystem-agnostic specification which standardizes the syntax and location information 19 | of software components. 20 | 21 | - **Pedigree** - Data which describes the lineage and/or process for which software has been created or altered. 22 | 23 | - **Point of origin** - The supplier and associated metadata from which a software component has been procured, 24 | transmitted, or received. Package repositories, release distribution platforms, and version control history 25 | are examples of various points of origin. 26 | 27 | - **Procurement** – The process of agreeing to terms and acquiring software or services for later use. 28 | 29 | - **Provenance** - The chain of custody and origin of a software component. Provenance incorporates the point of 30 | origin through distribution as well as derivatives in the case of software that has been modified. 31 | 32 | - **Software bill of materials (SBOM)** – A complete, formally structured, and machine-readable inventory of all 33 | software components and associated metadata, used by or delivered with a given piece of software. 34 | 35 | - **Software Identification (SWID)** - An ISO standard that formalizes how software is tagged. 36 | 37 | - **Software Package Data Exchange (SPDX)** - A Linux Foundation project which produces a software bill of materials 38 | specification and a standardized list of open source licenses. 39 | 40 | - **Third-party component** – Any software component not directly created including open source, "source available", 41 | and commercial or proprietary software. 42 | 43 | - **Transitive dependency** - A software component that is indirectly used by a program by means of being a dependency 44 | of a dependency. 45 | 46 |
47 | \newpage 48 |
49 | -------------------------------------------------------------------------------- /en/0x91-Appendix-B_References.md: -------------------------------------------------------------------------------- 1 | # Appendix B: References 2 | 3 | The following resources may be useful to users and adopters of this standard: 4 | 5 | ## OWASP Projects 6 | 7 | * [OWASP Packman](https://github.com/OWASP/packman) 8 | * [OWASP Software Assurance Maturity Model (SAMM)](https://owasp.org/www-project-samm/) 9 | 10 | 11 | ## Community Projects 12 | * [Open Source Security Foundation: Threats, Risks, and Mitigations in the Open Source Ecosystem](https://github.com/ossf/wg-identifying-security-threats/tree/main/publications/threats-risks-mitigations) 13 | 14 | 15 | ## Others 16 | 17 | * [InnerSource](https://www.oreilly.com/library/view/adopting-innersource/9781492041863/ch01.html) 18 | * [Cybersecurity Maturity Model Certification (CMMC)](https://dodcio.defense.gov/CMMC/) 19 | * [NIST 800-53 Security and Privacy Controls for Federal Information Systems and Organizations](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf) 20 | * [NIST 800-161 Supply Chain Risk Management Practices for Federal Information Systems and Organizations](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-161.pdf) 21 | * [NIST 800-171 Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations](https://csrc.nist.gov/publications/detail/sp/800-171/rev-2/final) 22 | * [NTIA Documents on Software Bill of Materials](https://www.ntia.doc.gov/SBOM) 23 | * [Model Procurement Contract Language Addressing Cybersecurity Supply Chain Risk](https://www.eei.org/-/media/Project/EEI/Documents/Issues-and-Policy/Model--Procurement-Contract.pdf) 24 | * [Guide on Cybersecurity Procurement Language in Task Order Requests for Proposals for Federal Facilities](https://www.pnnl.gov/main/publications/external/technical_reports/PNNL-28661.pdf) 25 | * [Energy Sector Control Systems Working Group (ESCSWG)](https://www.energy.gov/sites/prod/files/2014/04/f15/CybersecProcurementLanguage-EnergyDeliverySystems_040714_fin.pdf) 26 | 27 | 28 | ## SBOM Formats 29 | 30 | * [CycloneDX](https://cyclonedx.org/) 31 | * [SPDX](https://spdx.org/) 32 | * [SPDX XML](https://spdx-ccm.specchain.org/xsdccm/home) 33 | * [ISO/IEC 19770-2:2015 (SWID)](https://www.iso.org/standard/65666.html) 34 | -------------------------------------------------------------------------------- /en/images/license.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/OWASP/Software-Component-Verification-Standard/5d9dc6de3c2bf029b160abeb7c38ed41137dc473/en/images/license.png -------------------------------------------------------------------------------- /en/images/owasp_logo_1c_notext.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/OWASP/Software-Component-Verification-Standard/5d9dc6de3c2bf029b160abeb7c38ed41137dc473/en/images/owasp_logo_1c_notext.png -------------------------------------------------------------------------------- /export.py: -------------------------------------------------------------------------------- 1 | #!/usr/bin/python 2 | 3 | ''' Tool for converting the SCVS requirements to various formats. 4 | 5 | Usage: ./export.py [--format /dev/null 2>&1; 8 | } 9 | 10 | if ! command_exists pandoc; then 11 | echo "Error: Please install pandoc. Cannot continue" 12 | exit; 13 | fi 14 | 15 | generate_docx() { 16 | pandoc -s -f gfm --reference-doc=../templates/reference.docx \ 17 | --lua-filter=../templates/pagebreak.lua \ 18 | --columns 10000 \ 19 | -t docx \ 20 | -o "../OWASP_SCVS-SNAPSHOT-$1.docx" *.md 21 | } 22 | 23 | # generate_html() { 24 | # pandoc -s -f markdown_github -t html5 -o "../OWASP_SCVS-SNAPSHOT-$1.html" *.md 25 | # } 26 | 27 | generate() { 28 | echo -n "Generating OWASP SCVS ($1)..." 29 | if [ -d "$1" ]; 30 | then 31 | cd "$1" 32 | generate_docx $1 33 | # generate_html $1 34 | cd .. 35 | echo " done." 36 | else 37 | echo " No OWASP SCVS found in directory $1" 38 | fi 39 | } 40 | 41 | # Arabic 42 | #generate "ar" 43 | 44 | # Brazil 45 | #generate "br" 46 | 47 | # Chinese 48 | #generate "cn" 49 | 50 | # Czech 51 | #generate "cz" 52 | 53 | # English 54 | generate "en" 55 | 56 | # French 57 | #generate "fr" 58 | 59 | # German 60 | # generate "de" 61 | 62 | # Hebrew 63 | #generate "heb" 64 | 65 | # Italian 66 | #generate "it" 67 | 68 | # Japanese 69 | #generate "jp" 70 | 71 | # Korean 72 | #generate "kr" 73 | 74 | # Spanish 75 | # generate "es" 76 | 77 | # Ukraine 78 | #generate "ukr" 79 | 80 | echo 81 | echo "Generated OWASP Software Component Verification Standard" 82 | -------------------------------------------------------------------------------- /scvs.py: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env python 2 | 3 | ''' SCVS document parser and converter class. 4 | 5 | Based upon code written for MASVS By Bernhard Mueller and later adopted for ASVS 6 | 7 | Copyright (c) 2017 OWASP Foundation 8 | 9 | Permission is hereby granted, free of charge, to any person obtaining a copy 10 | of this software and associated documentation files (the "Software"), to deal 11 | in the Software without restriction, including without limitation the rights 12 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 13 | copies of the Software, and to permit persons to whom the Software is 14 | furnished to do so, subject to the following conditions: 15 | 16 | The above copyright notice and this permission notice shall be included in all 17 | copies or substantial portions of the Software. 18 | 19 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 20 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 21 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 22 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 23 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 24 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 25 | SOFTWARE. 26 | 27 | ''' 28 | 29 | import os 30 | import re 31 | import json 32 | from xml.sax.saxutils import escape 33 | import csv 34 | 35 | try: 36 | from StringIO import StringIO 37 | except ImportError: 38 | from io import StringIO 39 | 40 | 41 | class SCVS: 42 | ''' Creates requirements list out of markdown files. ''' 43 | scvs = {} 44 | scvs['domains'] = [] 45 | language = "en" 46 | flat_requirements = [] 47 | 48 | def __init__(self): 49 | regex = re.compile('Version (([\d.]+){3})') 50 | 51 | for line in open(os.path.join(self.language, "0x01-Frontispiece.md"), encoding="utf8"): 52 | m = re.search(regex, line) 53 | if m: 54 | self.scvs['version'] = m.group(1) 55 | break 56 | 57 | regex = re.compile('## About the Standard\n\n(.*)') 58 | 59 | with open(os.path.join(self.language, "0x01-Frontispiece.md"), encoding="utf8") as content: 60 | m = re.search(regex, content.read()) 61 | if m: 62 | self.scvs['description'] = m.group(1) 63 | 64 | for file in sorted(os.listdir(self.language)): 65 | if re.match("0x\d{2}-V", file): 66 | regex = re.compile('0x\d{2}-(V([0-9]{1,3}))-(\w[^-.]*)') 67 | m = re.search(regex, file) 68 | if m: 69 | domain = {} 70 | domain['shortcode'] = m.group(1) + "-" + m.group(3) 71 | domain['ordinal'] = int(m.group(2)) 72 | domain['name'] = m.group(3).replace("_", " ") 73 | domain['objective'] = "" 74 | domain['requirements'] = [] 75 | 76 | regex2 = re.compile('(?<=## Control Objective\n\n)(.*)(?=\n## Verification Requirements)', re.M | re.S) 77 | with open(os.path.join(self.language, file), encoding="utf8") as content: 78 | m2 = re.search(regex2, content.read()) 79 | if m2: 80 | domain['objective'] = m2.group(1).strip().replace('\n', ' ').replace(' ', ' ') 81 | 82 | for line in open(os.path.join(self.language, file), encoding="utf8"): 83 | regex = re.compile('\*\*([\d\.]+)\*\*\s\|\s{0,1}(.*?)\s{0,1}\|([\w\d,\. \u2713]*)\|([\w\d,\. \u2713]*)\|([\w\d,\. \u2713]*)\|') 84 | m = re.search(regex, line) 85 | if m: 86 | req = {} 87 | req['id'] = m.group(1) 88 | req['text'] = m.group(2) 89 | req['l1'] = bool(m.group(3).strip()) 90 | req['l2'] = bool(m.group(4).strip()) 91 | req['l3'] = bool(m.group(5).strip()) 92 | req['file'] = file 93 | self.flat_requirements.append(req) 94 | domain['requirements'].append(req) 95 | 96 | self.scvs['domains'].append(domain) 97 | def to_raw_model(self): 98 | return self.scvs 99 | 100 | def to_json(self): 101 | ''' Returns a JSON-formatted string ''' 102 | return json.dumps(self.flat_requirements) 103 | 104 | def to_xml(self): 105 | ''' Returns XML ''' 106 | xml = "\n" 107 | xml += "\n" 108 | 109 | for r in self.flat_requirements: 110 | xml += "\t" \ 114 | + escape(r['text']) + "\n" 115 | 116 | xml += "\n" 117 | return xml 118 | 119 | def to_csv(self): 120 | ''' Returns CSV ''' 121 | si = StringIO() 122 | 123 | writer = csv.DictWriter(si, ['id', 'text', 'l1', 'l2', 'l3', 'file']) 124 | writer.writeheader() 125 | writer.writerows(self.flat_requirements) 126 | 127 | return si.getvalue() 128 | -------------------------------------------------------------------------------- /templates/pagebreak.lua: -------------------------------------------------------------------------------- 1 | --- Return a block element causing a page break in the given format. 2 | local function newpage(format) 3 | if format == 'docx' then 4 | local pagebreak = '' 5 | return pandoc.RawBlock('openxml', pagebreak) 6 | elseif format:match 'html.*' then 7 | return pandoc.RawBlock('html', '
') 8 | elseif format:match 'tex$' then 9 | return pandoc.RawBlock('tex', '\\newpage{}') 10 | elseif format:match 'epub' then 11 | local pagebreak = '

' 12 | return pandoc.RawBlock('html', pagebreak) 13 | else 14 | -- fall back to insert a form feed character 15 | return pandoc.Para{pandoc.Str '\f'} 16 | end 17 | end 18 | 19 | -- Filter function called on each RawBlock element. 20 | function RawBlock (el) 21 | -- check that the block is TeX or LaTeX and contains only \newpage or 22 | -- \pagebreak. 23 | if el.text:match '\\newpage' then 24 | -- use format-specific pagebreak marker. FORMAT is set by pandoc to 25 | -- the targeted output format. 26 | return newpage(FORMAT) 27 | end 28 | -- otherwise, leave the block unchanged 29 | return nil 30 | end 31 | -------------------------------------------------------------------------------- /templates/reference.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/OWASP/Software-Component-Verification-Standard/5d9dc6de3c2bf029b160abeb7c38ed41137dc473/templates/reference.docx --------------------------------------------------------------------------------