The IT world is full of interesting scenarios, some of which are a far cry from reality. Here are two different perspectives on the use of modules in code:
General Imagination:
- Use modules in code so that a single place can be fortified with all necessary precautions.
- If a third-party developer finds a security flaw, they fix it.
- Everyone else uses the updated version, making the world instantly more secure.
Ground Reality:
- Use modules to save time for development and reduce headaches.
- Freeze the version because we don’t fully trust third-party developers to keep going in the same direction as us.
- New approaches from version freezing to hash-based mapping reduce the risk of version being easily overwritten but not the code commit hash.
- When news about OSS developers modifying code against policies is popularised, benefitting parties spread the news that you can’t trust modules.
- A security bug appears in the code, the author fixes it, and everyone using the module (or at least those who are aware) fixes it as well. Those using the software update their code bases, and this cascades down to lower levels.
If all goes well maybe, just maybe, in the next 5 years, we’ll be able to create a more secure world. /s
So, What wrong here:
- who’s at fault?
- What can be done to reduce unnecessary loops?
- Is fixating on third-party dependencies the right approach, or should the focus be somewhere else?
These are interesting questions living rent free in my head with no clear answers
#security #development #software #developer #appsec #webapplicationsecurity #infosec #dependencies #dependencymanagement #thirdpartyriskmanagement #riskmanagement