3 ms·
You might need to reframe your terminology on what "software fragility" is referring to. If you mean looking into critical failures in systems due to vulnerabil
by tsumnia 4y ago
You might need to reframe your terminology on what "software fragility" is referring to. If you mean looking into critical failures in systems due to vulnerabilities in third-party libraries (I'm thinking Log4JS), then the terminology currently used in security is "software supply chain" [1].
My general process is once you've found an article, like the "Backstabber's knife collection: A review of open source software supply chain attacks" from my link, read through it with a text editor open. Make notes like a summary of what they did, what they found, strengths and weaknesses, and what I like to call "the rabbit hole". If you see a reference to something you're curious about, find what the citation for that piece of information is and follow up with a reading of that article next. Repeat until you've exhausted the findings and move on to the next interesting reference.
[1] https://scholar.google.com/scholar?as_ylo=2019&q=software+supply+chain&hl=en&as_sdt=0,34 https://scholar.google.com/scholar?as_ylo=2019&q=software+su...
- fedeb95 4y agoIt's not that I'm referring to. It's how likely a change in software will cause more bugs. Specifically, how a bug fix could result in more bugs because of interconnections (that's some layman definition I've constructed based on online stuff)
- tsumnia 4y agoLooking at your other responses, "software supply chain" may still be a fruitful term to look through. While my example referred to how a dependency could be a vulnerability, you might find something about how updates to those dependencies introduce bugs. I'm thinking about like how changes to Python 3 broke everything. Software supply chains aren't my area of research, but given your descriptions, it sounds like it will still provide worthwhile information.