See to Believe: Using Visualization To Motivate Updating Third-party Dependencies

May 15, 2024 Β· Declared Dead Β· πŸ› International Joint Conference on Computer Science and Software Engineering

πŸ‘» CAUSE OF DEATH: Ghosted
No code link whatsoever

"No code URL or promise found in abstract"

Evidence collected by the PWNC Scanner

Authors Chaiyong Ragkhitwetsagul, Vipawan Jarukitpipat, Raula Gaikovina Kula, Morakot Choetkiertikul, Klinton Chhun, Wachirayana Wanprasert, Thanwadee Sunetnanta arXiv ID 2405.09074 Category cs.SE: Software Engineering Citations 2 Venue International Joint Conference on Computer Science and Software Engineering Last Checked 4 months ago
Abstract
Security vulnerabilities introduced by applications using third-party dependencies are on the increase, caused by the emergence of large ecosystems of libraries such as the NPM packages for JavaScript. Nowadays, libraries depend on each other. Relying on these large ecosystems thus means that vulnerable dependencies are not only direct but also indirect (transitive) dependencies. There are automated tool supports to manage these complex dependencies but recent work still shows that developers are wary of library updates, even to fix vulnerabilities, citing that being unaware, or that the migration effort to update outweighs the decision. In this paper, we hypothesize that the dependency graph visualization (DGV) approach will motivate developers to update, especially when convincing developers. To test this hypothesis, we performed a user study involving 20 participants divided equally into experimental and control groups, comparing the state-of-the-art tools with the tasks of reviewing vulnerabilities with complexities and vulnerabilities with indirect dependencies. We find that 70% of the participants who saw the visualization did re-prioritize their updates in both tasks. This is higher than the 30% and 60% of the participants who used the npm audit tool in both tasks, respectively.
Community shame:
Not yet rated
Community Contributions

Found the code? Know the venue? Think something is wrong? Let us know!

πŸ“œ Similar Papers

In the same crypt β€” Software Engineering

Died the same way β€” πŸ‘» Ghosted