Identity your risks

- [Instructor] As organizations continue to adopt more and more third-party services, it becomes that much more important to have a process in place for assessing supply chain risk. The first step in this process is to identify the risks to your software supply chain. Risk identification starts with an understanding of the scope of your risk assessment. While the other domains of the CSSLP focus primarily on software you've developed internally, your assessment of the software supply chain will require that you turn your attention outward. Just like the production and distribution of a physical good often involves a number of individuals and organizations, the production and distribution of software also involves multiple participants. For starters, who's providing either code or services for your application? Many, if not most, applications today include open-source software components. A recent study by Black Duck, an organization that specializes in software composition analysis, found that 35% of commercial apps were using open-source components. When they added internally developed apps to their list, that number jumped to 75%. If your development team is leveraging any commercial off-the-shelf software as a component of their application infrastructure, then you'll have less visibility into the security of those components than you'll have in your open-source components. Content management systems like Microsoft SharePoint are prime examples of COTS applications, and with our ever increasing push for more and more cloud-based services, you're likely to have SaaS, PaaS, and IaaS components in your app infrastructure that are supplied by a third party. Armed with an understanding of your software supply chain participants, you can then turn your attention to the potential threats to those participants that could impact your app downstream. Whether it's the open-source community, a third-party developer, or a third-party service provider, no one in your software supply chain is immune to attack. In the secure software design domain, we covered the concept of threat modeling. You can apply those same concepts here when identifying threats to your software supply chain. You'll just want to adjust your perspective a bit first. When assessing security threats, start with your open-source components. You're likely to find vulnerabilities in those open-source components. Sometimes they're a result of insecure coding practices, while other times they're put there intentionally by malicious actors. Regarding your COTS components and your as-a-service providers, see if you can leverage existing threat models or risk assessments that may have already been completed. Combine that information with open-source intelligence gathering and you'll have a decent idea of the threats that could impact your application. But don't limit your assessment to only security risks. Make sure you're including financial risks as well. Those open-source components may come with licensing restrictions that could result in legal issues if you don't read the fine print. And an as-a-service provider who isn't financially stable could disappear overnight. Round out your risk identification efforts by examining operational risks as well. Remember those service-level agreements we discussed in secure software deployment, operations, and maintenance? Compare your internal SLAs to the SLAs from your providers. Hopefully someone did that before signing any contracts, but it doesn't hurt to double check. And don't forget to leverage OWASP when performing this activity. The community maintains the Software Component Verification Standard, or SCVS, as a framework to help guide you in managing software supply chain risks. The SCVS lists 87 unique controls relevant to a secure software supply chain, grouping those controls into six families: inventory, software bill of materials, build environment, package management, component analysis, and pedigree and provenance. Each control is assigned a verification level, one for low assurance, two for moderate assurance, and three for high assurance. Those verification levels depend on the data sensitivity or the use of the software. I recommend that you download the SCVS and review it before taking your CSSLP exam. It's a fairly short read, only 17 pages, but the information contained within is stuff you'll come back to again and again throughout your career. Regarding service providers, one last component of risk that I recommend you consider is visibility. You're putting your trust in not just their technology, but in their overall security program. Part of that trust is that they'll handle security incidents appropriately and keep you reasonably informed. An immature security program could result in limited visibility into security incident response activity or into the post-incident forensics necessary to fully resolve that incident and take action on lessons learned. The maturity of their security program should be in scope for your risk identification efforts. Likewise, you should include the visibility you have into their financial stability and their operational stability. This visibility will be a key factor in the next step of your risk assessment process. Identifying the risks in your software supply chain is a crucial first step in addressing those risks. Once you have an understanding of those risks, you're ready to move on to the next step, assessing those risks.