Interstitial risk: when two secure systems make one vulnerable one

7 points by raphtheb a day ago | 3 comments

evan_a_a a day ago |
The author is describing a practice that is already well known: Systems engineering. Applied well, systems engineering helps prevent many of these issues from happening in the first place. Unfortunately, outside of heavily regulated industries or critical systems (like aerospace, as mentioned), systems engineering practices are rarely applied with the proper level of discipline.
raphtheb a day ago |
You are correct: the formal discipline of Systems Engineering, done with appropriate levels of rigor, fits this.
That said, in most software orgs, "systems engineer" doesn't mean that discipline anymore. When the title's actually used in job postings, it's almost universally infrastructure/ops, servers, reliability. The name got co-opted by a different, unrelated role in most software companies (At least the subset i have visibility into!). A hiring manager looking to hire a "systems engineer" for interface discipline would likely get a stack of infrastructure resumes instead.
That's part of why the gap persists. It's not that the discipline doesn't exist, it's that even its name doesn't point at it anymore for large swathes of the industry.
tancop 13 hours ago |
> In the old worker, that input would have failed loudly or been coerced away harmlessly. In the new one, it underflows an array index.
this cant happen if the new service is really written in rust, unless you ignore all the best practices and use unsafe pointer manipulation without manual bounds checks.
services should be built to assume all input is untrusted even if its from an internal source, thats security 101. if your code can expose confidential data or crash instead of returning an error that means your code is wrong. none of this is "interstitial risk" just good old missing validation and failure to handle problems gracefully.