3 ms·
Impressive achievement. It still sounds like callee's have more knowledge of callers than is justified. Is it a security property or a component functionality p
by angry_octet 7y ago
Impressive achievement. It still sounds like callee's have more knowledge of callers than is justified. Is it a security property or a component functionality property? How do those interact?
A centralised graph representation of the security/functionality properties would be a better way to represent this information, so it can catch adding interfaces which should be forbidden. Also able to be configuration managed as sets of microservices.
If you have a connectivity graph it would be good to do taint analysis to see how far bad information can propagate.
- p10jkle 7y agoI think we do effectively have a graph, but its not stored in a centralised way. If it was, then we'd have to somehow gatekeep that state, which when you consider that we do hundreds of deployments a day, becomes tricky
- angry_octet 7y agoThen the state at present is changing hundreds of times a day, without being centrally visible, via runtime query or configuration service. Seems like it would be hard to retrospectively analyze what could connect to what. Maybe consider a permissive system, that allows a service code change to change the connectivity graph without a review step, but centrally logs the change; another service can supervise what's happening, and alert if strange things happen. It would help to have a system for categorising service types; the graph properties of the system might be useful for understanding that. Looking at service changes in terms of graph properties, like edit distance, can also be useful.
- p10jkle 7y agoI feel like we could do all of that by consuming the GitHub API. We essentially have directed graph stored as files