2 ms·

Intuitively it seems like logging and error reporting software would be prime targets for supply chain attacks, as they have access to a treasure trove of explo

Intuitively it seems like logging and error reporting software would be prime targets for supply chain attacks, as they have access to a treasure trove of exploitable data. A strategic modification in some tiny transitive dependency or two and your logging server could log not just for you. Presumably, gathered data could be used to deanonymize users or exploit your software. How do people go about vetting and/or self-hosting those, if you operate [software for] a business with actual customers? Is stripping sensitive data at the client enough? Do you lock down outgoing connections through external networking configuration if you self-host? Am I being too paranoid?

d4mi3n 4y ago
This is an interesting topic I've explored a bit. The tldr; is that if your business can't afford or recover from a vendor having an incident, you shouldn't be using a vendor. This is often why highly regulated industries are slower moving and more expensive to operate: You need to either spend a lot of time vetting your vendors with policy (via contracts, compliance requirements, certification requirements) and practice (sign NDAs and review source code for components of interest, run joint penetration tests, fund bug bounty programs). That said, there are mitigations you can take. There are end-to-end encrypted log solutions out there. Honeycomb.io used to have (they might still?) an interesting offering I used at one employer to encrypt sensitive fields in logs leaving our infrastructure. They had the UI set up to talk to our encryption service and decode things on the fly in the user's browser-side UI so that they (Honeycomb) never had direct, unfettered access to sensitive data. There are other approaches you can take, but things get tricky when you either need to audit your vendor's access to your data or assume that your vendor can't secure your data to your satisfaction. Better to do it yourself at that point if you have the resourcing to do so.

d4mi3n 4y ago

This is an interesting topic I've explored a bit. The tldr; is that if your business can't afford or recover from a vendor having an incident, you shouldn't be using a vendor. This is often why highly regulated industries are slower moving and more expensive to operate: You need to either spend a lot of time vetting your vendors with policy (via contracts, compliance requirements, certification requirements) and practice (sign NDAs and review source code for components of interest, run joint penetration tests, fund bug bounty programs). That said, there are mitigations you can take. There are end-to-end encrypted log solutions out there. Honeycomb.io used to have (they might still?) an interesting offering I used at one employer to encrypt sensitive fields in logs leaving our infrastructure. They had the UI set up to talk to our encryption service and decode things on the fly in the user's browser-side UI so that they (Honeycomb) never had direct, unfettered access to sensitive data. There are other approaches you can take, but things get tricky when you either need to audit your vendor's access to your data or assume that your vendor can't secure your data to your satisfaction. Better to do it yourself at that point if you have the resourcing to do so.