A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | Supply chain Levels for Software Artifacts (SLSA) | SLSA LEVEL | NIST SSDF v1.1 | Additional | NIST 800-53r5 | EO14028 | NIST SP800-161r1 | CNCF | ||||||||||||||||||
2 | Source Requirement | Description | 1 | 2 | 3 | 4 | ||||||||||||||||||||
3 | Version controlled | Every change to the source is tracked in a version control system that meets the following requirements - [Change history] - [Immutable reference] | O | ✓ | ✓ | ✓ | NIST SSDF PS.3.1: Securely archive the necessary files and supporting data (e.g., integrity verification information, provenance data) to be retained for each software release. PS.1.1: Store all forms of code – including source code, executable code, and configuration-as-code – based on the principle of least privilege so that only authorized personnel, tools, services, etc. have access. PW.4.1: Acquire and maintain well-secured software components (e.g., software libraries, modules, middleware, frameworks) from commercial, opensource, and other third-party developers for use by the organization’s software. | SA-10, SA-15, SA-15(11), SR-4 PROVENANCE Control: Document, monitor, and maintain valid provenance of the following systems, system components, and associated data | 4e(iii): employing automated tools, or comparable processes, to maintain trusted source code supply chains, thereby ensuring the integrity of the code 4e(vi): maintaining accurate and up-to-date data, provenance (i.e., origin) of software code or components, and controls on internal and third-party software components, tools, and services present in software development processes, and performing audits and enforcement of these controls on a recurring basis; 4e(ix): attesting to conformity with secure software development practices; 4e(x): ensuring and attesting, to the extent practicable, to the integrity and provenance of open source software used within any portion of a product. | SR-4: Provenance should be documented for systems, system components, and associated data throughout the SDLC | ||||||||||||||||
4 | Verified history | Every change in the revision’s history has at least one strongly authenticated actor identity (author, uploader, reviewer, etc.) and timestamp.It must be clear which identities were verified, and those identities must use two-step verification or similar. | ✓ | ✓ | PS.1.1: Store all forms of code – including source code, executable code, and configuration-as-code – based on the principle of least privilege so that only authorized personnel, tools, services, etc. have access. PS.3.1: Securely archive the necessary files and supporting data (e.g., integrity verification information, provenance data) to be retained for each software release. PW.4.1: Acquire and maintain well-secured software components (e.g., software libraries, modules, middleware, frameworks) from commercial, opensource, and other third-party developers for use by the organization’s software. | SA-8 SR-4 PROVENANCE Control: Document, monitor, and maintain valid provenance of the following systems, system components, and associated data Discussion: "....document any changes to the provenance," | 4e(iii): employing automated tools, or comparable processes, to maintain trusted source code supply chains, thereby ensuring the integrity of the code
4e(ix): attesting to conformity with secure software development practices; 4e(x): ensuring and attesting, to the extent practicable, to the integrity and provenance of open source software used within any portion of a product. | SR-4: Provenance should be documented for systems, system components, and associated data throughout the SDLC | ||||||||||||||||||
5 | Retained indefinitely | The revision and its change history are preserved indefinitely and cannot be deleted, except when subject to an established and transparent policy for obliteration, such as a legal or policy requirement. - [Immutable history] - [Limited retention for SLSA 3] | 18 mo | ✓ | NIST SSDF PS.3.1: Securely archive the necessary files and supporting data (e.g., integrity verification information, provenance data) to be retained for each software release. PS.1.1: Store all forms of code – including source code, executable code, and configuration-as-code – based on the principle of least privilege so that only authorized personnel, tools, services, etc. have access. NIST SSDF - (PO.3): PO.3.3 - Example 3: Establish and enforce security and retention policies for artifact data. | AU-10 (1): NON-REPUDIATION | ASSOCIATION OF IDENTITIES
This enhancement helps traceability in the supply chain and facilitates the accuracy of provenance AU-10 (2): NON-REPUDIATION | VALIDATE BINDING OF INFORMATION PRODUCER IDENTITY This enhancement validates the relationship of provenance and a component within the supply chain. Therefore, it ensures integrity of provenance. SR-4: Provenance should be documented for systems, system components, and associated data throughout the SDLC | ||||||||||||||||||||
6 | Two-person reviewed | Every change in the revision’s history was agreed to by two trusted persons prior to submission, and both of these trusted persons were strongly authenticated. (Exceptions from Verified History apply here as well.) | ✓ | NIST SSDF PW.7.1: Determine whether code review (a person looks directly at the code to find issues) and/or code analysis (tools are used to find issues in code, either in a fully automated way or in conjunction with a person) should be used, as defined by the organization. PW.7.2: : Perform the code review and/or code analysis based on the organization’s secure coding standards, and record and triage all discovered issues and recommended remediations in the development team’s workflow or issue tracking system. | SA-11 | 4e(iv): employing automated tools, or comparable processes, that check for known and potential vulnerabilities and remediate them, which shall operate regularly, or at a minimum prior to product, version, or update release; 4e(ix): attesting to conformity with secure software development practices; | AC-(5): The enterprise should ensure that an appropriate separation of duties is
established for decisions that require the acquisition of both information system and supply chain components SR-4: Provenance should be documented for systems, system components, and associated data throughout the SDLC | |||||||||||||||||||
7 | Build requirements | 1 | 2 | 3 | 4 | |||||||||||||||||||||
8 | Scripted build | All build steps were fully defined in some sort of “build script”. The only manual command, if any, was to invoke the build script. | ✓ | ✓ | ✓ | ✓ | NIST SSDF PO3.1 Specify which tools or tool types must or should be included in each toolchain to mitigate identified risks, as well as how the toolchain components are to be integrated with each other. PW.6.1: Use compiler, interpreter, and build tools that offer features to improve executable security. PW6.2: Determine which compiler, interpreter, and build tool features should be used and how each should be configured, then implement and use the approved configurations. PO 3.2 Follow recommended security practices to deploy, operate, and maintain tools and toolchains. | SA-15 | 4e(iii): employing automated tools, or comparable processes, to maintain trusted source code supply chains, thereby ensuring the integrity of the code 4e(ix): attesting to conformity with secure software development practices; | SR-4: Provenance should be documented for systems, system components, and associated data throughout the SDLC | Cloud Native Computing Foundation: Supply Chain Best Practices : Securing Materials—Verification; Securing Build Pipelines—Verification, Automation, Secure Authentication/Access; Securing Artefacts—Verification; Securing Deployments—Verification | |||||||||||||||
9 | Build service | All build steps ran using some build service, not on a developer’s workstation. | ✓ | ✓ | ✓ | NIST SSDF PO3.2 : Follow recommended security practices to deploy, operate, and maintain tools and toolchains. PW.6.1: Use compiler, interpreter, and build tools that offer features to improve executable security. PW6.2: Determine which compiler, interpreter, and build tool features should be used and how each should be configured, then implement and use the approved configurations. | SA-15 | 4e(i)(F): secure software development environments- monitoring operations and alerts and responding to attempted and actual cyber incidents 4e(ii): generating and, when requested by a purchaser, providing artifacts that demonstrate conformance to the processes set forth in subsection (e)(i) of this section 4e(iii): employing automated tools, or comparable processes, to maintain trusted source code supply chains, thereby ensuring the integrity of the code 4e(v): providing, when requested by a purchaser, artifacts of the execution of the tools and processes described in subsection (e)(iii) and (iv) of this section, and making publicly available summary information on completion of these actions, to include a summary description of the risks assessed and mitigated 4e(vi): maintaining accurate and up-to-date data, provenance (i.e., origin) of software code or components, and controls on internal and third-party software components, tools, and services present in software development processes, and performing audits and enforcement of these controls on a recurring basis 4e(ix): attesting to conformity with secure software development practices | SR-4: Provenance should be documented for systems, system components, and associated data throughout the SDLC | CNCFSSCP: Securing Build Pipelines—Verification, Automation, Controlled Environments, Secure Authentication/Access; Securing Artefacts—Verification, Automation, Controlled Environments, Encryption; Securing Deployments—Verification, Automation | ||||||||||||||||
10 | Build as code | The build definition and configuration is defined in source control and is executed by the build service. | ✓ | ✓ | NIST SSDF PO3.3 Configure tools to generate artifacts of their support of secure software development practices as defined by the organization. | SA-15 | 4e(i)(F): secure software development environments- monitoring operations and alerts and responding to attempted and actual cyber incidents 4e(ii): generating and, when requested by a purchaser, providing artifacts that demonstrate conformance to the processes set forth in subsection (e)(i) of this section 4e(v): providing, when requested by a purchaser, artifacts of the execution of the tools and processes described in subsection (e)(iii) and (iv) of this section, and making publicly available summary information on completion of these actions, to include a summary description of the risks assessed and mitigated 4e(ix): attesting to conformity with secure software development practices | AU-10 (1): NON-REPUDIATION | ASSOCIATION OF IDENTITIES This enhancement helps traceability in the supply chain and facilitates the accuracy of provenance AU-10 (2): NON-REPUDIATION | VALIDATE BINDING OF INFORMATION PRODUCER IDENTITY This enhancement validates the relationship of provenance and a component within the supply chain. Therefore, it ensures integrity of provenance. SR-4: Provenance should be documented for systems, system components, and associated data throughout the SDLC | CNCFSSCP: Securing Build Pipelines—Verification, Automation, Controlled Environments; Securing Artefacts—Verification | |||||||||||||||||
11 | Ephemeral environment | The build service ensured that the build steps ran in an ephemeral environment, such as a container or VM, provisioned solely for this build, and not reused from a prior build. | ✓ | ✓ | NIST SSDF PO4.1 Define criteria for software security checks and track throughout the SDLC. PO 5.1 Separate and protect each environment involved in software development. | SA-15, SA-15(1) |
4e(iv): employing automated tools, or comparable processes, that check for known and potential vulnerabilities and remediate them, which shall operate regularly, or at a minimum prior to product, version, or update release 4e(v): providing, when requested by a purchaser, artifacts of the execution of the tools and processes described in subsection (e)(iii) and (iv) of this section, and making publicly available summary information on completion of these actions, to include a summary description of the risks assessed and mitigated 4e(ix): attesting to conformity with secure software development practices | "AU-10 (1): NON-REPUDIATION | ASSOCIATION OF IDENTITIES
This enhancement helps traceability in the supply chain and facilitates the accuracy of provenance AU-10 (2): NON-REPUDIATION | VALIDATE BINDING OF INFORMATION PRODUCER IDENTITY This enhancement validates the relationship of provenance and a component within the supply chain. Therefore, it ensures integrity of provenance. SR-4: Provenance should be documented for systems, system components, and associated data throughout the SDLC" | ||||||||||||||||||
12 | Isolated | The build service ensured that the build steps ran in an isolated environment free of influence from other build instances, whether prior or concurrent. | ✓ | ✓ | NIST SSDF PO5.1: Separate and protect each environment involved in software development. PO3.2 Follow recommended security practices to deploy, operate, and maintain tools and toolchains. PW 6.1 Use compiler, interpreter, and build tools that offer features to improve executable security. PW 6.2 Determine which compiler, interpreter, and build tool features should be used and how each should be configured, then implement and use the approved configurations. | SA-3(1), SA-8, SA-15 | 4e(i): secure software development environments: (A) using administratively separate build environments; (B) auditing trust relationships; (C) establishing multi-factor, risk-based authentication and conditional access across the enterprise; (D) documenting and minimizing dependencies on enterprise products that are part of the environments used to develop, build, and edit software; (F) monitoring operations and alerts and responding to attempted and actual cyber incidents; , 4e(ii): generating and, when requested by a purchaser, providing artifacts that demonstrate conformance to the processes set forth in subsection (e)(i) of this section 4e(iii): employing automated tools, or comparable processes, to maintain trusted source code supply chains, thereby ensuring the integrity of the code) 4e(v): providing, when requested by a purchaser, artifacts of the execution of the tools and processes described in subsection (e)(iii) and (iv) of this section, and making publicly available summary information on completion of these actions, to include a summary description of the risks assessed and mitigated 4e(vi): maintaining accurate and up-to-date data, provenance (i.e., origin) of software code or components, and controls on internal and third-party software components, tools, and services present in software development processes, and performing audits and enforcement of these controls on a recurring basis 4e(ix): attesting to conformity with secure software development practices | "AU-10 (1): NON-REPUDIATION | ASSOCIATION OF IDENTITIES
This enhancement helps traceability in the supply chain and facilitates the accuracy of provenance AU-10 (2): NON-REPUDIATION | VALIDATE BINDING OF INFORMATION PRODUCER IDENTITY This enhancement validates the relationship of provenance and a component within the supply chain. Therefore, it ensures integrity of provenance. SR-4: Provenance should be documented for systems, system components, and associated data throughout the SDLC" | CNCFSSCP: Securing Build Pipelines—Controlled Environments | |||||||||||||||||
13 | Parameterless | The build output cannot be affected by user parameters other than the build entry point and the top-level source location. In other words, the build is fully defined through the build script and nothing else. | ✓ | NIST SSDF PW6.2 Determine which compiler, interpreter, and build tool features should be used and how each should be configured, then implement and use the approved configurations. PO3.2 Follow recommended security practices to deploy, operate, and maintain tools and toolchains. PW6.1 Use compiler, interpreter, and build tools that offer features to improve executable security. | SA-15, SR-9 | 4e(iv): employing automated tools, or comparable processes, that check for known and potential vulnerabilities and remediate them, which shall operate regularly, or at a minimum prior to product, version, or update release 4e(ix): attesting to conformity with secure software development practices" | AU-10 (1): NON-REPUDIATION | ASSOCIATION OF IDENTITIES
This enhancement helps traceability in the supply chain and facilitates the accuracy of provenance AU-10 (2): NON-REPUDIATION | VALIDATE BINDING OF INFORMATION PRODUCER IDENTITY This enhancement validates the relationship of provenance and a component within the supply chain. Therefore, it ensures integrity of provenance. SR-4: Provenance should be documented for systems, system components, and associated data throughout the SDLC | CNCFSSCP: Securing Build Pipelines—Verification, Automation | ||||||||||||||||||
14 | Hermetic | All transitive build steps, sources, and dependencies were fully declared up front with immutable references, and the build steps ran with no network access. | ✓ | NIST SSDF PW.6.2: Determine which compiler, interpreter, and build tool features should be used and how each should be configured, then implement and use the approved configurations. PO 3.2 Follow recommended security practices to deploy, operate, and maintain tools and toolchains. PO 5.1 Separate and protect each environment involved in software development. PW 6.1 Use compiler, interpreter, and build tools that offer features to improve executable security. | AU-10 (1): NON-REPUDIATION | ASSOCIATION OF IDENTITIES
This enhancement helps traceability in the supply chain and facilitates the accuracy of provenance AU-10 (2): NON-REPUDIATION | VALIDATE BINDING OF INFORMATION PRODUCER IDENTITY This enhancement validates the relationship of provenance and a component within the supply chain. Therefore, it ensures integrity of provenance. SR-4: Provenance should be documented for systems, system components, and associated data throughout the SDLC | |||||||||||||||||||||
15 | Reproducible | Re-running the build steps with identical input artifacts results in bit-for-bit identical output. Builds that cannot meet this MUST provide a justification why the build cannot be made reproducible. | O | NIST SSDF PW.6.2: Determine which compiler, interpreter, and build tool features should be used and how each should be configured, then implement and use the approved configurations. PO3.2 Follow recommended security practices to deploy, operate, and maintain tools and toolchains. PW 6.1 Use compiler, interpreter, and build tools that offer features to improve executable security. | AU-10 (1): NON-REPUDIATION | ASSOCIATION OF IDENTITIES This enhancement helps traceability in the supply chain and facilitates the accuracy of provenance AU-10 (2): NON-REPUDIATION | VALIDATE BINDING OF INFORMATION PRODUCER IDENTITY This enhancement validates the relationship of provenance and a component within the supply chain. Therefore, it ensures integrity of provenance. SR-4: Provenance should be documented for systems, system components, and associated data throughout the SDLC | |||||||||||||||||||||
16 | Provenance | 1 | 2 | 3 | 4 | |||||||||||||||||||||
17 | Available | The provenance is available to the consumer in a format that the consumer accepts. The format SHOULD be in-toto SLSA Provenance, but another format MAY be used if both producer and consumer agree and it meets all the other requirements. | ✓ | ✓ | ✓ | ✓ | NIST SSDF PS.3.2: Collect, safeguard, maintain, and share provenance data for all components of each software release (e.g., in a software bill of materials [SBOM]). PO 4.1 Define criteria for software security checks and track throughout the SDLC. PS 2.1 Make software integrity verification information available to software acquirers. PS 3.1 Securely archive the necessary files and supporting data (e.g., integrity verification information, provenance data) to be retained for each software release. | NTIASBOM: All CNCFSSCP: Securing Materials—Verification, Automation SCTPC: MAINTAIN3 | SA-8, SR-3, SR-4 | 4e(vi): maintaining accurate and up-to-date data, provenance (i.e., origin) of software code or components, and controls on internal and third-party software components, tools, and services present in software development processes, and performing audits and enforcement of these controls on a recurring basis; 4e(ix): attesting to conformity with secure software development practices; 4e(vii): providing a purchaser a Software Bill of Materials (SBOM) for each product directly or by publishing it on a public website; 4e(x): ensuring and attesting, to the extent practicable, to the integrity and provenance of open source software used within any portion of a product. | AU(3): The audit records of a supply chain event should be securely handled and maintained in a manner that conforms to record retention requirements and preserves the integrity of the findings and the confidentiality of the record information and its sources as appropriate SR-4: Provenance should be documented for systems, system components, and associated data throughout the SDLC | CNCFSSCP: Securing Materials—Verification, Automation SCTPC: MAINTAIN3 | ||||||||||||||
18 | Authenticated | The provenance’s authenticity and integrity can be verified by the consumer. This SHOULD be through a digital signature from a private key accessible only to the service generating the provenance. | ✓ | ✓ | ✓ | NIST SSDF PS.2.1: Make software integrity verification information available to software acquirers PO 4.1 Define criteria for software security checks and track throughout the SDLC. PS 2.1 Make software integrity verification information available to software acquirers. | AU(3): The audit records of a supply chain event should be securely handled and maintained in a manner that conforms to record retention requirements and preserves the integrity of the findings and the confidentiality of the record information and its sources as appropriate SR-4: Provenance should be documented for systems, system components, and associated data throughout the SDLC CM(14): Enterprises should verify that the acquired hardware and software components are genuine and valid by using digitally signed components from trusted certificate authorities | |||||||||||||||||||
19 | Service generated | The data in the provenance MUST be obtained from the build service (either because the generator is the build service or because the provenance generator reads the data directly from the build service). | ✓ | ✓ | ✓ | NIST SSDF PS.3.2: Collect, safeguard, maintain, and share provenance data for all components of each software release (e.g., in a software bill of materials [SBOM]). PS 2.1 Make software integrity verification information available to software acquirers. | Dept of Commerce Minimum Elements for an SBOM | SR-4: Provenance should be documented for systems, system components, and associated data throughout the SDLC | ||||||||||||||||||
20 | Non-falsifiable | Provenance cannot be falsified by the build service’s users. | ✓ | ✓ | NIST SSDF PS.3.2: Collect, safeguard, maintain, and share provenance data for all components of each software release (e.g., in a software bill of materials [SBOM]). PS 2.1 Make software integrity verification information available to software acquirers. | NTIA SBOM collection of materials | AU(3): The audit records of a supply chain event should be securely handled and maintained in a manner that conforms to record retention requirements and preserves the integrity of the findings and the confidentiality of the record information and its sources as appropriate SR-4: Provenance should be documented for systems, system components, and associated data throughout the SDLC | |||||||||||||||||||
21 | Dependencies complete | Provenance records all build dependencies that were available while running the build steps. | ✓ | NIST SSDF PS.3.2: Collect, safeguard, maintain, and share provenance data for all components of each software release (e.g., in a software bill of materials [SBOM]). PO 4.1 Define criteria for software security checks and track throughout the SDLC. PS 2.1 Make software integrity verification information available to software acquirers. | SR-4: Provenance should be documented for systems, system components, and associated data throughout the SDLC | |||||||||||||||||||||
22 | Common requirements | 1 | 2 | 3 | 4 | |||||||||||||||||||||
23 | Security | The system meets some TBD baseline security standard to prevent compromise. (Patching, vulnerability scanning, user isolation, transport security, secure boot, machine identity, etc. Perhaps NIST 800-53 or a subset thereof.) | ✓ | NIST SSDF PW.8.2: Scope the testing, design the tests, perform the testing, and document the results, including recording and triaging all discovered issues and recommended remediations in the development team’s workflow or issue tracking system. (SSDF uses major vulnerability, significant vulnerability, residual vulnerability, risk based approach text NIST SSDF PW.4.4 Example 5: Determine a plan of action for each software component that is no longer being maintained or will not be available in the near future. PO3.2 Follow recommended security practices to deploy, operate, and maintain tools and toolchains. PO 5.1 Separate and protect each environment involved in software development. PO 5.2 Secure and harden development endpoints (i.e., endpoints for software designers, developers, testers, builders, etc.) to perform development-related tasks using a risk-based approach. PS 3.1 Securely archive the necessary files and supporting data (e.g., integrity verification information, provenance data) to be retained for each software release. PW 6.2 Determine which compiler, interpreter, and build tool features should be used and how each should be configured, then implement and use the approved configurations. | AT-3, CP-2, CP-3, CP-8, CP-9, IR-3, IR-4, PL-2, PM-14, SR-2. | SR-4: Provenance should be documented for systems, system components, and associated data throughout the SDLC RA-5 VULNERABILITY MONITORING AND SCANNING RA-3 RISK ASSESSMENT | ||||||||||||||||||||
24 | Access | All physical and remote access must be rare, logged, and gated behind multi-party approval. | ✓ | NIST SSDF PO.3.2 Example 6: Continuously monitor tools and tool logs for potential operational and security issues, including policy violations and anomalous behavior. NIST SSDF PO 5.1 Example 4: Minimize direct human access to toolchain systems, such as build services. Continuously monitor and audit all access attempts and all use of privileged access. NIST SSDF PO 5.1 Example 9: Continuously monitor all software deployed in each environment for new vulnerabilities, and respond to vulnerabilities appropriately following a risk-based approach. NIST SSDF PO 5.2 Example 3: Continuously monitor the security posture of all development endpoints, including monitoring and auditing all use of privileged access | CM-5 ACCESS RESTRICTIONS FOR CHANGE Control: Define, document, approve, and enforce physical and logical access restrictions associated with changes to the system. | SR-4: Provenance should be documented for systems, system components, and associated data throughout the SDLC | ||||||||||||||||||||
25 | Superusers | Only a small number of platform admins may override the guarantees listed here. Doing so MUST require approval of a second platform admin. | ✓ | PO 5.2 Example 2: Configure each development endpoint and the development resources to provide the least functionality needed by users and services and to enforce the principle of least privilege. PS 1.1: Store all forms of code – including source code, executable code, and configuration-as-code – based on the principle of least privilege so that only authorized personnel, tools, services, etc. have access. | SR-4: Provenance should be documented for systems, system components, and associated data throughout the SDLC | |||||||||||||||||||||
26 | ||||||||||||||||||||||||||
27 | ||||||||||||||||||||||||||
28 | ||||||||||||||||||||||||||
29 | ||||||||||||||||||||||||||
30 | ||||||||||||||||||||||||||
31 | ||||||||||||||||||||||||||
32 | ||||||||||||||||||||||||||
33 | ||||||||||||||||||||||||||
34 | ||||||||||||||||||||||||||
35 | ||||||||||||||||||||||||||
36 | ||||||||||||||||||||||||||
37 | ||||||||||||||||||||||||||
38 | ||||||||||||||||||||||||||
39 | ||||||||||||||||||||||||||
40 | ||||||||||||||||||||||||||
41 | ||||||||||||||||||||||||||
42 | ||||||||||||||||||||||||||
43 | ||||||||||||||||||||||||||
44 | ||||||||||||||||||||||||||
45 | ||||||||||||||||||||||||||
46 | ||||||||||||||||||||||||||
47 | ||||||||||||||||||||||||||
48 | ||||||||||||||||||||||||||
49 | ||||||||||||||||||||||||||
50 | ||||||||||||||||||||||||||
51 | ||||||||||||||||||||||||||
52 | ||||||||||||||||||||||||||
53 | ||||||||||||||||||||||||||
54 | ||||||||||||||||||||||||||
55 | ||||||||||||||||||||||||||
56 | ||||||||||||||||||||||||||
57 | ||||||||||||||||||||||||||
58 | ||||||||||||||||||||||||||
59 | ||||||||||||||||||||||||||
60 | ||||||||||||||||||||||||||
61 | ||||||||||||||||||||||||||
62 | ||||||||||||||||||||||||||
63 | ||||||||||||||||||||||||||
64 | ||||||||||||||||||||||||||
65 | ||||||||||||||||||||||||||
66 | ||||||||||||||||||||||||||
67 | ||||||||||||||||||||||||||
68 | ||||||||||||||||||||||||||
69 | ||||||||||||||||||||||||||
70 | ||||||||||||||||||||||||||
71 | ||||||||||||||||||||||||||
72 | ||||||||||||||||||||||||||
73 | ||||||||||||||||||||||||||
74 | ||||||||||||||||||||||||||
75 | ||||||||||||||||||||||||||
76 | ||||||||||||||||||||||||||
77 | ||||||||||||||||||||||||||
78 | ||||||||||||||||||||||||||
79 | ||||||||||||||||||||||||||
80 | ||||||||||||||||||||||||||
81 | ||||||||||||||||||||||||||
82 | ||||||||||||||||||||||||||
83 | ||||||||||||||||||||||||||
84 | ||||||||||||||||||||||||||
85 | ||||||||||||||||||||||||||
86 | ||||||||||||||||||||||||||
87 | ||||||||||||||||||||||||||
88 | ||||||||||||||||||||||||||
89 | ||||||||||||||||||||||||||
90 | ||||||||||||||||||||||||||
91 | ||||||||||||||||||||||||||
92 | ||||||||||||||||||||||||||
93 | ||||||||||||||||||||||||||
94 | ||||||||||||||||||||||||||
95 | ||||||||||||||||||||||||||
96 | ||||||||||||||||||||||||||
97 | ||||||||||||||||||||||||||
98 | ||||||||||||||||||||||||||
99 | ||||||||||||||||||||||||||
100 |