integrate ryan's feedback

_posts/2025-03-20-bitby-report.md

@@ -15,9 +15,10 @@ The assumptions we make about nation state actors at Distrust:
 * All keyboards are logging to the adversary
 * Any firmware/boot-loaders not verified on every boot are compromised
 * Any host OS with network access is compromised
-* Any guest OS used for any purpose other than prod access is compromised
+* Any guest OS used for any purpose other than production access is compromised
 * At least one member of the Production Team is always compromised
-* At least one maintainer of third party used in the system is compromised
+* At least one maintainer of third party code used in the system is compromised
+* At least one member of third party system used is compromised
 * Physical attacks are viable and likely
 * Side-channel attacks are viable and likely
 
@@ -50,7 +51,7 @@ Another way to mitigate this risk is to use a hardened server, such as a secure
 
 * This isn't the first time an attack like this happened. Those who have been around for a while will remember the [Axie Infinity Hack](https://www.bleepingcomputer.com/news/security/hackers-stole-620-million-from-axie-infinity-via-fake-job-interviews/) which also happend due to compromise of a developer who used their day to day machine for managing cryptographic material and accessing production systems.
 
-* The use of tools like MDM on systems for production access is not recommended, as they create a single point of failure. Most MDM solutions mean that a third party has complete access to the fleet of computers it's "protecting", and even if self hosted creates a large single point of failure which is challenging to mitigate to a resonable degree. Instead, the approach should rely on making the surface area for attack so minimal that introducing anything else introduces more risk than benefit. For illustrative pruposes, imagine a hardware-based virtual machine which only has a minimal operating system, the CLI tool for the preferred cloud platform, and a network interface which has a firewall configuration permitting only connections to a specific production asset. If this sytem is only used for accessing that specific asset, the introduction of anything additional, including an MDM or anti-malware/anti-virus software, actually increases the surface area for attack. Of course, this is a stepping stone to improve controls around accessing production systems until better mitigating controls can be put in place, making it impossible to directly interact with and change production systems as an individual.
+* The use of tools like Mobile Device Management on systems for production access is not recommended, as they create a single point of failure. Most MDM solutions mean that a third party has complete access to the fleet of computers it's "protecting", and even self hosted creates a large single point of failure which is challenging to mitigate to a resonable degree. Instead, the approach should rely on making the surface area for attack so minimal that introducing anything else introduces more risk than benefit. For illustrative pruposes, imagine a hardware-based virtual machine which only has a minimal operating system, the CLI tool for the preferred cloud platform, and a network interface which has a firewall configuration permitting only connections to a specific production asset. If this sytem is only used for accessing that specific asset, the introduction of anything additional, including an MDM or anti-malware/anti-virus software, actually increases the surface area for attack. Of course, this is a stepping stone to improve controls around accessing production systems until better mitigating controls can be put in place, making it impossible to directly interact with and change production systems as an individual.
 
 * Additional resiliency can be achieved by deploying a system for deployment across multiple accouts with different ownership or even different cloud platforms. This is out of scope of this report which focuses on mitigating controls where most companies should start their journey to improve their supply chain security.
 
@@ -74,7 +75,7 @@ Ensure that the bucket / server serving the website can not be modified by a sin
     * Use [ReprOS](https://codeberg.org/stagex/repros) to help with reproduction. It's a bare-bones immutable OS designed for securely reproducing and signing software. Each build is executed in a one-time use environment, eliminating persistent risks. It is in currently in beta testing. This project is currently in beta.
 
 #### Additional Notes
-All third party code should be manually reviewed. Currently most companies rely on SAST tools. This is not enough, as SAST tools are unable to detect novel exploits. The cost of using open source code, at a minimum, should be to review every line of code manually. If companies are so stringent about having developers review their first party code, why do companies choose to not apply the same principles to third party code? It is burdensome, but necessary for high risk targets. If you're unfamiliar a good example of what's possible with supply chain attacks is the [xz backdoor](https://en.wikipedia.org/wiki/XZ_Utils_backdoor).
+All third party code should be manually reviewed. Currently most companies rely on Static Application Security Testing tools. This is not enough, as SAST tools are unable to detect novel exploits. The cost of using open source code, at a minimum, should be to review every line of code manually. If companies are so stringent about having developers review their first party code, why do companies choose to not apply the same principles to third party code? It is burdensome, but necessary for high risk targets. If you're unfamiliar a good example of what's possible with supply chain attacks is the [xz backdoor](https://en.wikipedia.org/wiki/XZ_Utils_backdoor).
 
    - Distrust's answer to this is [SigRev](https://git.distrust.co/public/sigrev), which helps harness the power of nerds to create a repository of signed reports for reviews of open source software. The idea is that companies can come together to fund review of common open source software, to save money, and simultaneously help secure Open Source software. SIgRev has been designed, but is not yet in development and is seeking funding.
 
@@ -102,5 +103,5 @@ We have noticed that many companies still neglect basic security hygiene practic
 
 The Distrust team has helped build and secure some of the highest risks systems in the world such as the vaulting systems at BitGo, Unit410, and Turnkey as well as helping electrical grid operators, industrial control system operators and other. Through working with companies that are exposed to the most sophisticated known attackers where all attacks are viable, Distrust developed a methodology to help mitigate this level of threat. We are now using our hard learned lessons to help everyone improve their security posture by open sourcing all our learnings and creating open source tooling everyone can benefit from.
 
-You can learn more about what we are building on our [website](https://distrust.co)
+You can learn more about what we are building on our [website](https://distrust.co).
 

_sass/base.scss

@@ -1545,6 +1545,11 @@ pre {
 	margin: 80px 0px;
 }
 
+.blog a {
+	color: var(--light-grey);
+	text-decoration: underline;
+}
+
 /** end blog */
 
 *,