ABCDEFGHIJKLMNOPRSTUVWXYZ
1
Software supply chain security checklist(80) questions are selected!
2
Original statementSourceCategory-IDCategorySub-IDSub-categoryQuestion-IDQuestionSub-questionDescriptionLevelPhaseStakeholder groupStakeholderDomain
3
The responsible entity for a critical infrastructure asset must give the Secretary operational information in relation to the asset.Security of CI ActSTSoftware traceabilityST-01Component registrationST-01-01Do you have a process or policy to register the information of software components (e.g., SBOM) and secure software development attestations?The organization should have processes or policies for registering software components, such as SBOM (Software Bill of Materials) and securing attestations for software development.MandatoryPreparationProducerManagerGeneral
4
Security of CI ActSTSoftware traceabilityST-02Stakeholder communicationST-02-01Do you provide/share the information (software components, SBOM) to the relevant stakeholders?

This question is to understand whether the organization shares software component information (e.g., SBOM) with stakeholders.MandatoryDeploymentProducerOperatorGeneral
5
The responsible entity for one or more critical infrastructure assets must have, and comply with, a critical infrastructure risk management program.Security of CI ActRMRisk managementRM-01Risk programRM-01-01Do you establish risk management program in place to identify, manage and mitigate risks?This quesiton is to confirm if the organization has a risk management program to identify, manage, and mitigate risks. It should be documented and shared with stakeholders.MandatoryPreparationProducerManagerGeneral
6
A responsible entity must give an annual report relating to its critical infrastructure risk management program. Security of CI ActRMRisk managementRM-05Risk reportRM-04-01Do you provide a report (e.g., annual report) relating to the risk management program?There should be a formal report, such as an annual report, on its risk management program.MandatoryEntire life cycleProducerManagerGeneral
7
If a cyber security incident has a relevant impact on a critical infrastructure asset, the responsible entity for the asset may be required to give a relevant Commonwealth body a report about the incident.Security of CI ActIMIncident managementIM-01Incident reportIM-01-01Do you have a reporting system to provide cyber security incidents and information to the relevant stakeholders?The organization should have a system to report cybersecurity incidents to relevant stakeholders.
In addtion, there should be defined a reporting line.		MandatoryPost-deploymentProducerManagerGeneral
8
Security of CI ActIMIncident managementIM-01Incident reportIM-01-02Do you have a classification system for cybersecurity incidents and corresponding management processes?
For instance, do you distinguish between critical cybersecurity incidents and others, and do you have separate reporting processes for each?		The organization should implement a classification system for cybersecurity incidents, distinguishing between critical and non-critical incidents. Additionally, the organization should define specific reporting thresholds; for instance, critical incidents should be reported within 12 hours, while other security incidents should be reported within 72 hours.MandatoryPost-deploymentProducerManagerGeneral
9
The responsible entity for a system of national significance may be subject to statutory incident response planning obligations. (Part 2C, Subdivision B)Security of CI ActIMIncident managementIM-02Incident responseIM-02-01Do you have a incident response plan to the system and cyber security incidents?There should be a plan for responding to system and cybersecurity incidents.MandatoryPreparationProducerOperatorGeneral
10
Security of CI ActIMIncident managementIM-02Incident responseIM-02-02Do you comply with the response plan?This question is to ask whether the organization complies with the incident response plan.MandatoryEntire life cycleProducerOperatorGeneral
11
Security of CI ActIMIncident managementIM-02Incident responseIM-02-03Do you review the plan on a regular basis and ensure that the plan is up to date?The organization should regularly reviews the response plan.MandatoryEntire life cycleProducerOperatorGeneral
12
Certain information obtained or generated under, or relating to the operation of, this Act is protected information. There are restrictions on when a person may make a record of, use or disclose protected information.Security of CI ActDPData protectionDP-01Data policyDP-01-01Do you establish policy or process in place to protect information? There should be a policy or process for protecting information within the organization.MandatoryPreparationProducerManagerGeneral
13
Security of CI ActDPData protectionDP-02Data definitionDP-02-01Do you have the classfication and defintion of data/information?The organization should define and classify data according to its sensitivity or other factors.MandatoryDevelopmentProducerOperatorGeneral
14
Security of CI ActDPData protectionDP-01Data policyDP-01-03Do you restrict the creation/use/disclosure of data/information as per the data policy?The organization should ensure that data usage and disclosure are restricted in accordance with the data policy.MandatoryDevelopmentProducerOperatorGeneral
15
Provenance exists describing how the artifact was built, including the build platform, build process, and top-level inputs (Level 1)SLSASTSoftware traceabilityST-03Provenance managementST-03-01Do you have provenance to trace software back to the source?The organization should be able to trace software back to its source to ensure transparency and security.
Provenance should exist and describe how the artifact was built, including the build platform, build process, and top-level inputs.		RecommendedDeploymentProducerOperatorGeneral
16
SLSASBSoftware build and deploymentSB-03Build verificationSB-03-01Do you have/implement a verification process for provenance to prevent mistakes or incidents during the release process?The organization should verify software provenance to prevent release errors or incidents.RecommendedDeploymentProducerOperatorGeneral
17
SLSASBSoftware build and deploymentSB-03Build verificationSB-03-02Do you ensure that the builder in the provenance is trusted? The organization should ensure that the software builder is trusted.RecommendedDeploymentProducerOperatorGeneral
18
Dependency threats- (D) Use compromised dependency
Threat: The adversary injects malicious code into software required to build the artifact.		SLSASBSoftware build and deploymentSB-03Build verificationSB-03-04Do you verify the build dependecies in the provenance to ensure that there is no use of compromised dependency?The organization should verify that no compromised dependencies are used during the build process.AdvancedDeploymentProducerOperatorGeneral
19
Downstream verification of provenance includes validating the authenticity of the provenance. (Level 2)SLSASBSoftware build and deploymentSB-03Build verificationSB-03-03Do you verify the authenticity of the provenance?The organization should verify the authenticity of the provenance.AdvancedDeploymentProducerOperatorGeneral
20
Software producer follows a consistent build process so that others can form expectations about what a “correct” build looks like. (Level 1)SLSASBSoftware build and deploymentSB-01Build processSB-01-01Do you define a build process and manage/control the process?There should a defined, documented, and controlled process for building software.RecommendedDeploymentProducerOperatorGeneral
21
Configure Software to Have Secure Settings by Default (PW.9): Help improve the security of the software at the time of installation to reduce the likelihood of the software being deployed with weak security settings, putting it at greater risk of compromise.NISTSBSoftware build and deploymentSB-01Build processSB-01-02Do you define, document, and implement default settings as a secure baseline?The organization should implement default settings as a secure baseline for software builds.RecommendedDeploymentProducerOperatorGeneral
22
Software producer distributes provenance to consumers, preferably using a convention determined by the package ecosystem. (Level 1)SLSASTSoftware traceabilityST-02Stakeholder communicationST-02-02Do you establish a package ecosystem and define a rule to provide provenance to consumers?The organization should establish a rule for providing provenance in its package ecosystem.RecommendedDeploymentProducerOperatorGeneral
23
Build platform runs on dedicated infrastructure, not an individual’s workstation, and the provenance is tied to that infrastructure through a digital signature. (Level 2)SLSASBSoftware build and deploymentSB-02Build platformSB-02-01Do you run builds on a hosted platform that generates and signs the provenance? The build platform should operate on dedicated infrastructure rather than an individual's workstation, and the provenance is securely tied to that infrastructure through a digital signature.AdvancedDeploymentProducerOperatorGeneral
24
Build platform implements strong controls to: (Level 3)
. prevent runs from influencing one another, even within the same project.
. prevent secret material used to sign the provenance from being accessible to the user-defined build steps. 		SLSASBSoftware build and deploymentSB-02Build platformSB-02-02Do you use a hardened build platform with strong tamper protection? The platform should ensure run isolation within projects and safeguard secret material used for signing provenance from user-defined build steps.AdvancedDeploymentProducerOperatorGeneral
25
SLSASBSoftware build and deploymentSB-02Build platformSB-02-03Do you ensure that you can prevent runs from influencing one another, even within the same project?The organization should ensure that different builds do not influence each other, even within the same project.AdvancedDeploymentProducerOperatorGeneral
26
SLSASBSoftware build and deploymentSB-02Build platformSB-02-04Do you ensure that you can secret material used to sign the provenance from being accessible to the user-defined build steps?The organization should ensure that materials used to sign provenance are protected and not accessible by user-defined build steps.AdvancedDeploymentProducerOperatorGeneral
27
Define Security Requirements for Software
Development (PO.1): Ensure that security
requirements for software development are
known at all times so that they can be taken into
account throughout the SDLC and duplication of
effort can be minimized because the
requirements information can be collected once
and shared. This includes requirements from
internal sources (e.g., the organization’s policies,
business objectives, and risk management
strategy) and external sources (e.g., applicable
laws and regulations).		NISTSESecure environmentSE-01Software development security policySE-01-01Do you establish a policy/process for sofware development security applied entire software development life cycle? There should be a security policy applied throughout the entire software development lifecycle.MandatoryPreparationProducerOperatorGeneral
28
NISTSESecure environmentSE-02Software development security policySE-02-01Does the policy/process include security requirements for software development to meet or comply with?This is to check whether the software development process includes and complies with defined security requirements.MandatoryPreparationProducerOperatorGeneral
29
Review the Software Design to Verify Compliance with Security Requirements and Risk Information (PW.2): Help ensure that the software will meet the security requirements and satisfactorily address the identified risk information.NISTSDSecure software developmentSD-02Design reviewSD-02-01Do you review the software design to verify compliance with security requirements and
risk information?		The organization should review software design to verify compliance with security requirements and risk information.MandatoryDevelopmentProducerOperatorGeneral
30
Implement Roles and Responsibilities (PO.2): Ensure that everyone inside and outside of the organization involved in the SDLC is prepared to perform their SDLC-related roles and responsibilities throughout the SDLC.NISTAFAccountability frameworkAF-01Role and responsibilityAF-01-01Do you clearly define and document the roles and responsibilities and lines of communication for the software supply chain security?The organization should clearly define and document roles and responsibilities in the software supply chain.MandatoryPreparationProducerManagerGeneral
31
depend on an interconnected “system of systems”
[2]AFAccountability frameworkAF-01Role and responsibilityAF-01-02Do you define clear ownership, roles, and responsibilities with relevant CI sectors to share information and minimize threat escalation and propagation?The proliferation of interconnectivity and dependencies of these critical infrastructure systems has led to vulnerabilities.
The weakest link vulnerabilities, especially when threats escalate and propagate through Internet attack amplification.
Cascading repercussions.
Clear ownership, accountability and responsibility.
Information sharing.		RecommendedPreparationProducerManagerGeneral
32
Implement Supporting Toolchains (PO.3):
Use automation to reduce human effort and improve the accuracy, reproducibility, usability, and comprehensiveness of security practices throughout the SDLC, as well as provide a way to document and demonstrate the use of these
practices. Toolchains and tools may be used at different levels of the organization, such as organization-wide or project-specific, and may address a particular part of the SDLC, like a build pipeline.		NISTSTSoftware traceabilityST-04Record keepingST-04-01Do you manage record keeping of all relevant documentation and information and have supporting tool (toolchains)?The organization should maintain comprehensive record-keeping of all relevant documentation and information pertaining to the software system. This includes information of software development and operation (e.g., automatic recording of events such as logs) to facilitate continuous monitoring. RecommendedEntire life cycleProducerOperatorGeneral
33
Define and Use Criteria for Software Security Checks (PO.4): Help ensure that the software resulting from the SDLC meets the organization’s expectations by defining and using criteria for checking the software’s security during development.NISTSESecure environmentSE-03Security check criteriaSE-03-01Do you define and use criteria for software security checks?This includes the defintion of criteria and implementation process.MandatoryPreparationProducerOperatorGeneral
34
Implement and Maintain Secure Environments for Software Development (PO.5): Ensure that all components of the environments for software development are strongly protected from internal and external threats to prevent compromises of the environments or the software being developed or maintained within them. Examples of environments for software development include development, build, test, and distribution environments.NISTSESecure environmentSE-04Enviroment protectionSE-04-01Do you have mechanisms in place to protect secure environments for software development, including development, build, test, and distribution environments?This is to check if secure environments are in place for development, build, test, and distribution processes.MandatoryPreparationProducerOperatorGeneral
35
NISTSESecure environmentSE-04Enviroment protectionSE-04-02Do you separate and protect each environment involved in software development?The organization shoul development, build, and distribution environments are separated and protected.RecommendedDevelopmentProducerOperatorGeneral
36
NISTSESecure environmentSE-04Enviroment protectionSE-04-03Do you secure and harden development endpoints using a risk-based approach?The organization should consider that development endpoints are hardened using a risk-based approach.RecommendedDevelopmentProducerOperatorGeneral
37
Protect All Forms of Code from Unauthorized Access and Tampering (PS.1): Help prevent unauthorized changes to code, both inadvertent and intentional, which could circumvent or negate the intended security characteristics of
the software. For code that is not intended to be publicly accessible, this helps prevent theft of the software and may make it more difficult or time-consuming for attackers to find
vulnerabilities in the software.		NISTDPData protectionDP-03Access controlDP-01-04Do you store all forms of data (souce code, executable code, configuration, etc.) with least privilege access controls?This means that only authorized personnel, tools, services, etc. have access.MandatoryDevelopmentProducerOperatorGeneral
38
Archive and Protect Each Software Release (PS.3): Preserve software releases in order to help identify, analyze, and eliminate vulnerabilities discovered in the software after release.NISTSTSoftware traceabilityST-05Data archivingST-05-01Do you archive the necessary files/data including verification information and provenance data to be retained?The organization should archive files/data, including verification and provenance information.MandatoryPost-deploymentProducerOperatorGeneral
39
Reuse Existing, Well-Secured Software When Feasible Instead of Duplicating Functionality (PW.4): Lower the costs of software development, expedite software development, and decrease the likelihood of introducing additional security vulnerabilities into the software by reusing software modules and services that have already had their security posture checked. This is particularly important for software that implements security functionality, such as cryptographic modules and protocols.NISTSDSecure software developmentSD-01Reuse of existing componentSD-01-01Do you consider and reuse existing software components?This asks if the organization reuses existing software components.
This includes software libraries, modules,
middleware, frameworks) from commercial, opensource, and other third-party developers for use by the
organization’s software.		MandatoryProcurement/acquisitionProducerOperatorGeneral
40
NISTSDSecure software developmentSD-01Reuse of existing componentSD-01-02Do you verify the acquired software components if they comply with the security requirements?The organization should verify their compliance with security requirements.RecommendedProcurement/acquisitionProducerOperatorGeneral
41
Create Source Code by Adhering to Secure Coding Practices (PW.5): Decrease the number of security vulnerabilities in the software, and reduce costs by minimizing vulnerabilities introduced during source code creation that meet or exceed organization-defined vulnerability severity criteria.NISTSDSecure software developmentSD-03Secure codingSD-03-01Do you define and document secure coding practices?The organization should define secure coding practices.MandatoryDevelopmentProducerOperatorGeneral
42
NISTSDSecure software developmentSD-03Secure codingSD-03-02Do you create code based on the secure coding practices?The organization should implement secure coding practices based on the definition.MandatoryDevelopmentProducerOperatorGeneral
43
Configure the Compilation, Interpreter, and Build Processes to Improve Executable Security (PW.6): Decrease the number of security vulnerabilities in the software and reduce costs by eliminating vulnerabilities before testing occurs.NISTSDSecure software developmentSD-04Security TestingSD-04-07Do you use up-to-date versions of toolchain (e.g., compiler, interpreter, and build tools)?The organization should ensure that they use up-to-date versions of compilers, interpreters, and build tools are used to decrease the number of security vulnerabilities.MandatoryDevelopmentProducerOperatorGeneral
44
NISTSDSecure software developmentSD-04Security TestingSD-04-06Do you regularly validate the authenticity and integrity of toolchain (e.g., compiler, interpreter, and build tools) and verify that the approved configurations are being used?The organization should regularly validate the integrity and approved configurations of its toolchain.RecommendedDevelopmentProducerOperatorGeneral
45
Review and/or Analyze Human-Readable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements (PW.7): Help identify vulnerabilities so that they can be corrected before the software is released
to prevent exploitation. Using automated methods lowers the effort and resources needed to detect vulnerabilities. Human-readable code includes source code, scripts, and any other form of code that an organization deems humanreadable.		NISTSDSecure software developmentSD-03Secure codingSD-03-03Do you review code to identify vulnerabilities?Code review for vulnerabilities: The organization should review code to identify vulnerabilities.RecommendedDevelopmentProducerOperatorGeneral
46
Test Executable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements (PW.8): Help identify vulnerabilities so that they can be corrected before the software is released in order to prevent exploitation. Using automated methods lowers the effort and resources needed to detect vulnerabilities and improves traceability and repeatability. Executable code includes binaries, directly executed bytecode and source code, and any other form of code that an organization deems executable.NISTSDSecure software developmentSD-03Secure codingSD-03-04Do you test executable codes to identify vulnerabilities and ensure compliance with security requirements?The organization should implement executable code testing; if executable codes are tested to identify vulnerabilities and ensure compliance with security requirements.RecommendedDevelopmentProducerOperatorGeneral
47
Identify and Confirm Vulnerabilities on an Ongoing Basis (RV.1): Help ensure that vulnerabilities are identified more quickly so that they can be remediated more quickly in accordance with risk, reducing the window of opportunity for attackers.
Assess, Prioritize, and Remediate Vulnerabilities (RV.2): Help ensure that vulnerabilities are remediated in accordance with
risk to reduce the window of opportunity for attackers.
Analyze Vulnerabilities to Identify Their Root Causes (RV.3): Help reduce the frequency of vulnerabilities in the future.		NISTSDSecure software developmentSD-04Security TestingSD-04-04Do you identify vulnerabilities on an ongoing basis?Vulnerability check; The organization should identify vulnerabilities on an ongoing basis.MandatoryDevelopmentProducerOperatorGeneral
48
NISTSDSecure software developmentSD-04Security TestingSD-04-05Do you analyze the vulnerabilities and identify risks and root casuses to address them?Vulnerability check; The organization should ensure that vulnerabilities are analyzed to identify risks and root causes.RecommendedDevelopmentProducerOperatorGeneral
49
The concept of roles allows TUF to only trust information provided by the correctly designated party. The root role indicates which roles can sign for which projects.
The roles sign metadata, which TUF uses to create verifiable records about the state of a repository or application at a specified time. As such, clients can use it to make decisions on which files to update. Different metadata files provide different information, and will be signed by different roles.
There are four required top-level roles, each with their own metadata file.

Required: Root, Targets, Snapshot, Timestamp
Optional: There may also be any number of delegated target roles.
TUFAFAccountability frameworkAF-01Role and responsibilityAF-01-03Do you clearly define different roles (root, targets, snapshot role, timestamp role, mirrors role) for signing updates?The organization should check if roles for signing updates are clearly defined, such as root, target, snapshot, and timestamp roles.AdvancedPost-deploymentProducerOperatorGeneral
50
The signed metadata files always include an expiration date. This ensures that outdated metadata will be detected and that clients can refuse to accept metadata older than that which they've already seen.

Implementers of TUF may use any data format for metadata files. The examples here use a subset of the JSON object format. When calculating the digest of an object, we use the Canonical JSON format. Implementation-level detail about the metadata can be found in the spec.

Root Metadata
Targets Metadata/Delegated Targets Metadata
Snapshot Metadata
Timestamp Metadata		TUFSTSoftware traceabilityST-04Record keepingST-04-02Do you update metadata files and contain cryptographic hashes of update files?The organization should use metadata files containing information like cryptographic hashes of update files, signing keys, and expiry dates. This allows verification of update authenticity without needing the software to understand the underlying cryptography.
Th metadata should be signed by the defined roles:
e.g., Root metadata should be signed by Root role.		AdvancedPost-deploymentProducerOperatorGeneral
51
TUFSUSoftware updateSU-01Update verificationSU-01-02Do you ensure that all metadata for the updates are properly signed by required roles?AdvancedPost-deploymentProducerOperatorGeneral
52
TUFSUSoftware updateSU-01Update verificationSU-01-03Is there a mechanism to validate the expiry dates of metadata files for the updates?AdvancedPost-deploymentProducerOperatorGeneral
53
An application uses the framework to interact with one or more repositories. A repository is a conceptual source of target files of interest to the application. Each repository MAY have one or more mirrors as the providers of files to be downloaded. For example, each mirror may specify a different host where files can be downloaded from over HTTP.

The mirrors can be full or partial mirrors as long as the application-side of the framework can ultimately obtain all of the files it needs. A mirror is a partial mirror if it is missing files that a full mirror should have. If a mirror is intended to only act as a partial mirror, the metadata and target paths available from that mirror can be specified.

Roles, trusted keys, and target files are completely separate between repositories. A multi-repository setup is a multi-root system. When an application uses the framework with multiple repositories, the framework does not perform any "mixing" of the trusted content from each repository. It is up to the application to determine the significance of the same or different target files provided from separate repositories.
TUFSESecure environmentSE-05Repository systemSE-05-01Do you have one or more mirrors for repositories to store update files and metadata? There should be one or more mirrors to store update files and metadata in repositories.AdvancedPost-deploymentProducerOperatorGeneral
54
TUFSESecure environmentSE-05Repository systemSE-05-02Is there a clear separation between update files (targets) and metadata files in the repository?There should be a clear separation between update files and metadata files in repositories.AdvancedPost-deploymentProducerOperatorGeneral
55
Record the time at which the update began as the fixed update start time. Time is fixed at the beginning of the update workflow to allow an application using TUF to effectively pause time, in order to ensure that metadata which has a valid expiration time at the beginning of an update does not fail an expiration check later in the update workflow.TUFSTSoftware traceabilityST-04Record keepingST-04-03Do you record the fixed update start time at the beginning of the update workflow? The organization should record the start time of updates to ensure workflow integrity.RecommendedPost-deploymentProducerOperatorGeneral
56
Version N+1 of the root metadata file MUST have been signed by: (1) a THRESHOLD of keys specified in the trusted root metadata file (version N), and (2) a THRESHOLD of keys specified in the new root metadata file being validated (version N+1). When computing the THRESHOLD each KEY MUST only contribute one SIGNATURE. That is, each SIGNATURE which is counted towards the THRESHOLD MUST have a unique KEYID. Even if a KEYID is listed more than once in the "signatures" list a client MUST NOT count more than one verified SIGNATURE from that KEYID towards the THRESHOLD. If version N+1 is not signed as required, discard it, abort the update cycle, and report the signature failure. On the next update cycle, begin at step § 5.3 Update the root role and version N of the root metadata file.TUFSUSoftware updateSU-01Update verificationSU-01-01Do you have a mechanism/process to check the updates for an arbitrary software attack and verify that the targets metadata file hasn't been tampered with?The organization should ensure that mechanisms are in place to check updates for arbitrary attacks.AdvancedPost-deploymentProducerOperatorGeneral
57
The version number of the new root metadata (version N+1) MUST be exactly the version in the trusted root metadata (version N) incremented by one, that is precisely N+1. If the version of the new root metadata file is not N+1, discard it, abort the update cycle, and report the rollback attack.TUFSUSoftware updateSU-02Attack detectionSU-02-01Do you check the updates for a rollback attack?The organization should check rollback attacks.
The organization can Implement robust monitoring systems to detect any unusual changes and use version control systems to track change.		AdvancedPost-deploymentProducerOperatorGeneral
58
The expiration timestamp in the trusted root metadata file MUST be higher than the fixed update start time. If the trusted root metadata file has expired, abort the update cycle, report the potential freeze attack.TUFSUSoftware updateSU-02Attack detectionSU-02-02Do you check the updates for a freeze attack?The organization should check freeze attacks where malicious actors intentionally disrupt the normal operation of a system or network by freezing or halting its processes.
AdvancedPost-deploymentProducerOperatorGeneral
59
All keys, except those for the timestamp and mirrors roles, should be stored securely offline (e.g. encrypted and on a separate machine, in special-purpose hardware, etc.). This document does not prescribe how keys should be encrypted and stored, and so it is left to implementers of this document to decide how best to secure them.

To replace a compromised root key or any other top-level role key, the root role signs a new root.json file that lists the updated trusted keys for the role. When replacing root keys, an application will sign the new root.json file with both the new and old root keys. Any time such a change is required, the root.json file is versioned and accessible by version number, e.g., 3.root.json.
TUFSUSoftware updateSU-02Attack detectionSU-02-03Do you detect and respond to compromised signing keys in updates?The organization should detect and respond to compromised signing keys in updates. All keys should be stored securely offline (e.g. encrypted and on a separate machine, in special-purpose hardware, etc.).
The organization should verify the digital signatures of all software updates to ensure their authenticity.
In addtion, they should monitor systems for unusual activity, such as unexpected changes to software or network traffic, which may indicate a compromised signing key.		AdvancedPost-deploymentProducerOperatorGeneral
60
Threat scenarios: Security requirements intended to counter threats are not domain specific or exclude organizational requirements.
CISASPSoftware souring and procurementSP-01Security requirementSP-01-01Do you define security requirements for software acquisition which are domain specific and include organizational requirements?The organization should consider if security requirements for software acquisition are domain-specific.MandatoryProcurement/acquisitionConsumerConsumerGeneral
61
Keep security requriements and risks assessments up-to-date using bsuiness processes and require adqquate protection and control of geolocation of all data and metadata.CISASPSoftware souring and procurementSP-01Security requirementSP-01-02Do you ensure that the requirements are NOT out-of date?The organization should ensure that the security requirements are up-to-date.MandatoryProcurement/acquisitionConsumerConsumerGeneral
62
2.1.2 Product evaluation
Product evaluation is imperative as it ensures the producr compiles with standards. It also identifies prodect defects. The evaluation process includes performing an internal analysis of current market and supplier solutions. Next, input from a Request For Information (RFI) or Requesr For Proposal (RFP) for solutions is solicited, after which that input will be assessed tp determine whether requirements that incorporate security and SCRM have been met.		CISASPSoftware souring and procurementSP-04Product evaluationSP-04-02Do you conduct product evaluation to determine if the product meets the security requirements for selection?The oragnization should implement product evaluations to determine if security requirements are met.MandatoryProcurement/acquisitionConsumerConsumerGeneral
63
2.2.1 Acceptance of Product
Customers should take appropriate precautions prior to accepting the product from the supplier or developer. Upon initial receipt of the product, the customer should thoroughly examine it.		CISASPSoftware souring and procurementSP-04Product evaluationSP-04-03Do you conduct product evaluation to ensure that the product is secure/safe and meets all security requirements for acceptance?The oragnization should check if the product is secure/safe and meets all security requirements for acceptance.MandatoryProcurement/acquisitionConsumerConsumerGeneral
64
CISASPSoftware souring and procurementSP-04Product evaluationSP-04-01Do you test the product to identify potential threats? The organization should test products for potential threats, such as unknown or unverified components/changes.MandatoryProcurement/acquisitionConsumerConsumerGeneral
65
2.2.3. Assurance
An organization should minimize threats according to their risk tolerance. To satisfy this requirement, organizations should establish and support a risk management program by understanding the risks associated with their information assets through risk identification, risk analysis, and risk evaluation.		CISARMRisk managementRM-02Risk identificationRM-02-01Do you identify risks in the software supply chain?The organization should identify risks in the software supply chain and assesses their impact.MandatoryEntire life cycleProducerOperatorGeneral
66
The consequences are destructive/devastating.
There are many dependencies. If an attack happens on one system, it disrupts multiple other networks.		[1]RMRisk managementRM-03Risk assessementRM-03-02Do you check direct/indirect impacts of the identified risks (e.g., potential failure/cyber attacks) on the sector/other sectors?MandatoryEntire life cycleProducerOperatorGeneral
67
Consider proper backup/mitigation plan.[1]RMRisk managementRM-04Risk controlRM-05-01Do you consider/have a proper backup/mitigation plan to avoid/reduce the impacts?There should be a backup or mitigation plan in place to address identified risks in the supply chain.MandatoryEntire life cycleProducerOperatorGeneral
68
2.1.3 Contracts
Customers should draft contractual agreements to enable improved software supply chain security controls and mitigations. 		CISASPSoftware souring and procurementSP-02Contract managementSP-02-01Do you include all (complete) requirements for product acqusition in the contract?All product acquisition requirements should be included in contracts.MandatoryProcurement/acquisitionConsumerConsumerGeneral
69
2.2.3 Assurance
Adveraries, whether they are nation-states or individuals, are continually looking for weakness within an organization's information system environment. These weakness range from misconfigured systems to lapses in the security testing or validation process.		CISASDSecure software developmentSD-04Security TestingSD-04-08Do you conduct security test after integration inclduing all procured products and developed products?Security testing should be conducted after integrating all procured and developed products. This should include compromised components, backdoors, unknown documents/functions/features, etc.MandatoryDeploymentConsumerConsumerGeneral
70
2.2.3 Assurance
Thorough and comprohensive security testing and validation is crucial because it allows organizations to prevent attacks, incidents, threats, and networ compromises. Threats to information security can be in the form of software attacks or in the form of technical software failures or errors (e.g., bugs, code problems, etc.)		CISAIMIncident managementIM-03User reportIM-03-01Do you have a system in place for users to report bugs, errors, anomalies, or security concerns (e.g., supicious activities)?
There should be a system for users to report bugs, errors, or security concerns.MandatoryPost-deploymentConsumerConsumerGeneral
71
CI is susceptible to harm, incapacitation, damage, or destruction from both natural and human-caused (both intentional/accidental) incidents.[7]SESecure environmentSE-06Development modelSE-06-01Do you have a proper software development model to enable continuous security checks throughout the entire supply chain?In waterfall approaches, failures/risks may remain unnoticed until the final product is delivered.
Considering security in the loop, there should be continous security check and risks management (e.g., DevSecOps).		RecommendedPreparationProducerOperatorGeneral
72
Threat modeling is an integral part of eliciting system
security requirements and understanding possible vulnerabilities and attack scenarios for the purpose of clearly identifying risk and impact levels.		[8]SDSecure software developmentSD-04Security TestingSD-04-02Do you conduct threat modeling to identify potential vulnerabilities, considering systematic process?The organization should use threat modeling to identify potential vulnerabilities, considering systematic process (e.g., V-model).RecommendedPreparationProducerOperatorGeneral
73
Secure design is a culture and methodology that constantly evaluates threats and ensures that code is robustly designed and tested to prevent known attack methods. OWASP, ISMSDSecure software developmentSD-02Design reviewSD-02-03Do you establish a library of secure design patterns for reuse?The organization should maintain a library of secure design patterns for reuse.AdvancedDevelopmentProducerOperatorCommunication
Education
Financial
74
OWASP, ISMSDSecure software developmentSD-04Security TestingSD-04-03Do you identify and manage architectural design flaws with threat modeling? Architectural design flaws should be managed through threat modeling.AdvancedDevelopmentProducerOperatorCommunication
Education
Financial
75
Write unit and integration tests to validate that all critical flows are resistant to the threat model

Application security testing can assist software developers in identifying vulnerabilities in their applications. In doing so, static application security testing and dynamic application security testing should be performed in order to achieve comprehensive test coverage.

Vulnerability assessments and penetration tests must be conducted before systems are deployed to
production		OWASP, ISM, MDCFSDSecure software developmentSD-04Security TestingSD-04-01Do you conduct comprehensive software tests (threat modeling, unit test, integration tests, penetration test and security test etc) before software systems are deployed to production?The organization should conduct comprehensive software tests, such as unit, integration, penetration, and security tests, are conducted before deployment.MandatoryDevelopmentProducerOperatorGeneral
76
Introduce a structured tracking of security
defects and make knowledgeable decisions
based on this information.		OWASP SAMMRMRisk managementRM-03Risk assessementRM-03-01Do you keep an overview of the state of security defects across the organization?The organization should monitor the state of security defects across the organization.RecommendedDevelopmentProducerOperatorGeneral
77
Log Scope: Logs are collected for purposes such as auditing access, investigating incidents, reviewing disaster recovery. All systems that handle security-classified information that accept network connections or make access control (authentication and authorisation) decisions should record and retain logs and/or audit trail information. ICT cyber security,
OWASP		RMRisk managementRM-06Logging and monitoringRM-06-01Do you establish effective monitoring and alerting systems such that suspicious activities are detected and responded to quickly?The organization should check whether effective monitoring and alerting systems are in place to detect and respond to suspicious activities.MandatoryPost-deploymentProducerManagerCommunication
Education
Financial

(General?)
78
 The software development outsourced to a supplier must be supervised and monitored to ensure that all department security requirements are met.ICT cyber securitySPSoftware souring and procurementSP-02Contract managementSP-02-02Do you formalise outsourcing contracts to ensure that the department’s rights and interests are protected?Contracts should be formalized to protect the organization's rights and interests when outsourcing.MandatoryPreparationProducerOperatorCommunication
Education

(General?)
79
Manufacturers should analyze the entire system to understand the full environment and context in which the device is expected to operate.

E.g., A global system view should describe the overall medical device system, including the device itself and all internal and external connections. For interconnected and networked devices, this view should identify all interconnected elements, including any software update infrastructure(s), healthcare facility network impacts, intermediary connections or devices, cloud connections, patient home network impact		MDCFSDSecure software developmentSD-02Design reviewSD-02-02Do you analysis overall (e.g, medical) device system, including the device itself and all internal and external connections? The organization should analyze the overall systems, including internal and external connections.AdvancedDeploymentProducerOperatorHealth
80
Software verification (verifying the identity of the software source and the integrity of the software obtained from the software source) is a key control in preventing the introduction of malware or counterfeit software. OWASP,
NERC CIP,
CSA-STAR		SPSoftware souring and procurementSP-03Source verificationSP-03-01Do you use any method/tool (e.g., digital signatures, software supply chain security tool) to verify the integrity of (open source/procurement) software obtained from the software source ?An example of this is where an application relies upon plugins, libraries, or modules from untrusted sources, repositories, and content delivery networks (CDNs), or where software updates are downloaded without sufficient integrity verification and applied to the previously trusted application. Attackers could potentially upload their own updates to be distributed and run on all installations.MandatoryProcurement/acquisitionConsumerConsumerCommunication
Education
Financial
Energy

(General?)
81
OWASP,
NERC CIP,
CSA-STAR		SBSoftware build and deploymentSB-04Deployment verificationSB-04-01Do you consistently validate the integrity of deployed artifacts?The organization should validate the integrity of deployed software artifacts consistently.MandatoryDeploymentProducerOperatorCommunication
Education
Financial
Energy

(General?)
82
One tool to help manage supply chain risk as well as clearly identify and track the software incorporated into a device is an SBOM. An SBOM can aid in the management of security risks that exist throughout the software stack. A robust SBOM includes both the device manufacturer-developed components and third-party components, including purchased/licensed software and open-source software, and the upstream software dependencies , and whether there are any known vulnerabilities in those componentsMDCF, CSA-STARSTSoftware TraceabilityST-01Component registrationST-01-02Do you have any document/tool to track all your software components, dependencies, vulnerabilities and their relationships?The organization should track software components, dependencies, vulnerabilities, and their relationships using documents or tools.MandatoryDeploymentProducerOperatorHealth
Financial

(General?)
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100