The internet is composable. As part of it’s foundational architecture one can combine components and functionality in different ways to achieve technical outcomes (definition). It’s a hugely valuable capability and has benefited the world greatly, but it also poses a challenge for the common security model of blocking.

TL;DR: In a composable technology world your security controls probably have limited effectiveness.

Composability is pretty awesome; it let’s you build things faster, swap components and all thanks to APIs (Application Programming Interfaces - it’s how software parts talks to each other). However, it also means that the piece of software you’re communicating with could be consuming services from many other services and modules behind the scenes.

Let’s say there’s an evil(TM) web platform that you want to block; let’s call it evil.com. Your security engineers quickly configure your web filtering tool to block evil.com. Any of your technology, like browsers, trying to connect to evil.com will be blocked. Mission accomplished! Except evil.com offers an API that’s consumed by hundreds of other websites, so while you may have blocked direct access to evil.com, it’s still accessed by other websites or platforms that your user’s use.

If you’re really committed to the task of blocking use of evil.com by your users, you could start blocking these intermediate websites that you use evil.com’s API. However, there are few problems: first, how do you discover that the intermediate websites use evil.com’s API? Some websites share information about who which technology they use but it’s not done in a consistent manner; there isn’t an SBOM (Software Bill of Materials) for websites never mind SBOMS are (as of time of writing) only starting to get adopted by software vendors. Even if a website discloses which services they consume, what services do those services consume. It’s “turtles all the way down” in a composable world. Even if you could discover all the websites and services that consumed evil.com you’re still left with the anti-pattern of maintaining a block list that is forever expanding. Your ability to achieve your security objective of blocking access to evil.com is undermined by the evolving techology around you.

The second biggest problem is composability unintentionally promotes collateral damage. Even if you can discover all the websites and services that consume evil.com, some of those websites might be genuinely useful to your users and blocking them isn’t an option lest you impact your business. You could ask the provider of this useful website to remove that functionality via your contractual rights (assuming you have a contract) but that’s just a version of block lists involving lawyers and will take weeks or months assuming the service provider will agree and put it in their backlog/to do list.

Composability can also introduce invisible security debt. Software modules integrated into applications is a type of composability and Log4J (amongst others) taught us the hard way about hidden software debt and vulnerabilities. That pattern is also present in a composable world where a website consumes a service that consumes a services and somewhere in that chain, there’s a service that has security issues which ultimately expose your data or cause other harm. Composability has impacts on privacy too which is why Europe’s GDPR (see Article 28, section 4) forces a propagation of privacy rights down the supply chain.

To be clear, I’m not against composability; I think it’s the best thing since sliced bread. Composability is also a valuable property in security systems. What composability means is that your security likely doesn’t work as well as you expect. I don’t have a solution; it’s just something I wanted to recognize. IMHO even a partial control/defense is better than doing nothing; just don’t get a false sense of security.

footnote: yes, firms can block all access to the internet and only permit specific apps but that’s a rare pattern (employees don’t tend to like it) and still ultimately suffers from the same problem although likely at a much smaller scale.