3 ms·

Supply chain security is another interesting one. Both hardware and software. Products are built with components from many suppliers, from all over the world, a

Supply chain security is another interesting one. Both hardware and software. Products are built with components from many suppliers, from all over the world, and understanding the security of these is hard. All the current geopolitical excitability / nation state influences make this topical. NSA intercepting networking hardware and implanting monitoring, or AV software build pipelines being compromised; there’s a lot to think about and improve.

thephyber 7y ago
Along these lines, I've considered trying to come up with a system for evaluating risk to your software applications based on observable risk factors for any given (3rd party) library used in your application. Basically the idea revolves around identifying data points of risk for the project including: comprehensive unit tests, integration tests, public design documents, adhering to some non-trivial code standards, automated linting/static analysis, dynamic analysis, automation of builds, automated updating upstream libraries as soon as they are released, all project developers have some sort of public identity + verifiable employer + reputation. Bonus points for security audit, whitehat communication guidelines, bug bounty program with incentives, fast fixes for reported security issues. Negative points for the absence of any of these coding practices, slow to respond to security reports/incidents, lack of 2FA on accounts, high number of historical CVEs, difficult to protect languages/frameworks/architectures, etc. These likely aren't easy to identify (probably the largest reason this hasn't publicly happened yet), but imagine some of them can be automated or MTurked or at least approximated. I imagine the large nation-states (could) have dossiers on (many/most/all?) developers and code projects they have come across and their code projects.

thephyber 7y ago

Along these lines, I've considered trying to come up with a system for evaluating risk to your software applications based on observable risk factors for any given (3rd party) library used in your application. Basically the idea revolves around identifying data points of risk for the project including: comprehensive unit tests, integration tests, public design documents, adhering to some non-trivial code standards, automated linting/static analysis, dynamic analysis, automation of builds, automated updating upstream libraries as soon as they are released, all project developers have some sort of public identity + verifiable employer + reputation. Bonus points for security audit, whitehat communication guidelines, bug bounty program with incentives, fast fixes for reported security issues. Negative points for the absence of any of these coding practices, slow to respond to security reports/incidents, lack of 2FA on accounts, high number of historical CVEs, difficult to protect languages/frameworks/architectures, etc. These likely aren't easy to identify (probably the largest reason this hasn't publicly happened yet), but imagine some of them can be automated or MTurked or at least approximated. I imagine the large nation-states (could) have dossiers on (many/most/all?) developers and code projects they have come across and their code projects.