What's in a Package? Getting Visibility Into Dependencies Using Security-Sensitive API Calls

Introduction to the show: ident: Security Radio. Generated commentary on the latest security and cryptography papers.

Nadia: I'm Nadia.

Elias: And I'm Elias, here with Priya.

Nadia: We're looking at the paper: "What's in a Package? Getting Visibility Into Dependencies Using Security-Sensitive API Calls".

Elias: Here's the gist of the paper. This study proposes a novel methodology to construct a security-sensitive API list for an ecosystem and compares their prevalence across functionally similar package groups to aid developers in assessing dependency risks.

Nadia: The authors propose a three-pronged approach to identify security-sensitive APIs in an ecosystem, which includes "Ecosystem’s API documentation (in Java it is JDK), CVE fixes, and associated CWEs" as the research questions RQ1 (Page 2).

Elias: This process resulted in a list of 219 Java security-sensitive APIs (Page 4).

Nadia: The construction involved: 1.

Title and authors: Nadia: So we're looking at this paper, "What's in a Package? Getting Visibility Into Dependencies Using Security-Sensitive API Calls," and it’s about how to actually get visibility into what a dependency is doing before you even select it.

Elias: Exactly. The authors are proposing a way to help developers assess the security risks of their dependencies by identifying these security-sensitive APIs through call graph analysis, which they say is a novel methodology for constructing that list > (<ref:2408.02846#pg1>).

Priya: So, what's the core idea behind this list construction? It sounds like they're trying to pull information from three different places to build this security-sensitive API list > (<ref:2408.02846#pg2>).

Nadia: They use the ecosystem’s API documentation, which for Java is JDK Javadoc, and then they look at CVE fixes and associated CWEs > (<ref:2408.02846#pg2>).

Elias: And they combine that with a third step, using examples from MITRE CWEs for each of the unique CWEs found in those CVEs to find common exploitation patterns > (<ref:2408.02846#pg2>).

Priya: So, how many APIs are we talking about after all that process is done? I’m curious about the scale of this list construction > (<ref:2408.02846#pg1>).

Nadia: They ended up with a list of two hundred nineteen Java security-sensitive APIs, which they found through that three-pronged approach > (<ref:2408.02846#pg2>).

Elias: And then they didn't stop there; they analyzed the prevalence of these APIs using call graph analysis to see how different packages relate to each other in terms of security usage > (<ref:2408.02846#pg2>).

Priya: Call graph analysis sounds technical, but what does that actually show us about risk? Does it just tell us which packages are used together?

Nadia: It shows patterns between packages, specifically they compared groups of functionally similar packages to understand why some have similar or different security-sensitive API patterns > (<ref:2408.02846#pg2>).

Elias: They found a few key patterns in that analysis, like "Same Functionality, Different Implementation," where the expected functionality is fixed but different implementations lead to different security-sensitive API calls > (<ref:2408.02846#pg2>).

Priya: That makes sense. So, what about the developer side of things? Do people actually care about this kind of deep analysis when they're picking dependencies?

Nadia: They surveyed one hundred ten developers to see how they feel about using this security-sensitive API information in their dependency selection process > (<ref:2408.02846#pg2>).

Elias: The results showed that forty-four point six percent of respondents said they would consider this information when making a decision on dependencies > (<ref:2408.02846#pg9>).

Priya: What's the reasoning behind that consideration? Are people just blindly trusting the data, or is there a deeper reason for them to look at these API calls?

Nadia: Most of them said they either think functionality is still much more important, or that these security-sensitive APIs are necessary for the package to do what it's doing > (<ref:2408.02846#pg9>).

Elias: They mentioned a point from someone in the paper saying, "I would assume it does what it does for a reason" > (<ref:2408.02846#pg9>).

Priya: And what about actual actions? Are developers changing their habits based on this survey feedback?

Nadia: Only nine percent of respondents said they were actually removing unnecessary dependencies from their choices > (<ref:2408.02846#pg9>).

Elias: But the overall finding was that fifty point nine percent of developers think this information can be considered in their dependency selection process > (<ref:2408.02846#pg10>).

Priya: So, what’s the practical implication for someone just trying to choose a library for a project? What should they actually do with this knowledge?

Nadia: The paper argues that developers should factor in both the functionality and the corresponding security-sensitive API calls when judging what might be unnecessary > (<ref:2408.02846#pg10>).

Elias: They recommend incorporating this data alongside traditional criteria like functionality and popularity to enhance security during selection > (<ref:2408.02846#pg10>).

Priya: I wonder about the future work they suggest. What kind of tools are they calling for to actually make this information accessible?

Nadia: They recommend integrating an open-source tool that takes a call graph of packages as input and generates comparative visualizations of security-sensitive API calls into package management tools > (<ref:2408.02846#pg10>).

Elias: And they also suggest incorporating continuous security audits into CI/CD pipelines to track and mitigate risky dependencies over time > (<ref:2408.02846#pg10>).

Priya: It sounds like a comprehensive approach, combining identification, analysis, and tooling for the future. So, to wrap up this look at "What's in a Package? Getting Visibility Into Dependencies Using Security-Sensitive API Calls," what’s the main point for us?

Nadia: The main point is that developers should seriously consider the number and types of security-sensitive API calls in their dependencies when making decisions about which packages to use > (<ref:2408.02846#pg11>).

Elias: It moves dependency selection beyond just checking for known vulnerabilities or basic maintenance status > (<ref:2408.02846#pg1>).

Priya: I think it’s about giving developers a way to judge the actual resource access a package has, which is something metadata just can't show them > (<ref:2408.02846#pg1>).

Nadia: Exactly. We need better visibility into these potential sensitive resources for developers to make informed choices > (<ref:2408.02846#pg1>).

Elias: This paper provides a methodology for identifying that list, an analysis of their prevalence in open-source packages, and user perception data on using this information to select dependencies > (<ref:2408.02846#pg11>).

Priya: It’s a solid framework for thinking about dependency risk in practice > (<ref:2408.02846#pg11>).

The paper's summary: Nadia: So, to recap, this paper is proposing a new way for developers to see what security risks are hiding in their software dependencies by looking at how packages use specific system access points, like file systems or networks.

Elias: Right, it’s about moving beyond just checking if a package has a known bug and instead analyzing the actual calls it makes to sensitive resources.

Nadia: They build this list of security-sensitive APIs using three steps: looking at the official documentation, like the JDK for Java, then cross-referencing those with known vulnerability fixes from CVEs, and finally mapping those to specific exploitation examples from CWEs.

Elias: That sounds like a solid way to build a comprehensive inventory of potential trouble spots across an entire ecosystem.

Nadia: Exactly. They ended up with two hundred nineteen Java security-sensitive APIs just by doing that process on one ecosystem, which is already quite a list for developers to chew on.

Elias: And they didn't stop at just counting them; they used call graph analysis to see how these sensitive calls are distributed among different packages.

Nadia: That’s where the real insight comes in. They compared functionally similar packages—packages that are supposed to do the same job—and found patterns in how their security API usage differs or stays the same.

Elias: So, they found things like "Same Functionality, Different Implementation," meaning two packages doing the same thing might be using completely different sensitive APIs depending on how they were written.

Nadia: Or sometimes it’s just about "Different Features," where one web framework has a slightly different set of security-sensitive calls than another, which makes them unique in terms of risk profile.

Elias: That points toward the idea that when you select a package, the implementation details really matter for the security surface area.

Nadia: And they also found that modular designs, like HTTP client packages, tend to use fewer network APIs because they handle those calls in a very contained way.

Elias: It’s showing that structure and design choices in a dependency can directly influence the actual security exposure of your application.

Nadia: Then there’s the developer survey part; they asked one hundred ten people if they'd actually use this information when picking what to include in their project.

Elias: The results were pretty mixed, but over half of them said that this kind of security data could be a factor in their dependency selection process.

Nadia: They didn't say it was the only thing; most people still prioritize core functionality above everything else when they are making those choices.

Elias: They mentioned that they’d assume a package does what it does for a reason, which is true, but this paper suggests we should start asking *why* it does it and what security trade-offs that has.

Nadia: So the implication is that developers need to start factoring in these security API calls alongside traditional things like functionality and popularity when they're making those dependency decisions.

Elias: And the authors suggest a few things for the future, like building an open-source tool that visualizes these call graphs so it’s easier to actually see this information.

Nadia: Plus, they want to see continuous security audits built right into the development pipeline so we can keep tracking those risky dependencies over time as they evolve.

Elias: So, it’s about moving from a reactive security check to a more proactive understanding of the actual resource usage in the code you're bringing in.

Nadia: It shifts the focus from just patching known bugs to understanding how a package interacts with your entire system's sensitive areas.

Elias: That’s exactly what this study is trying to set up for developers, so next time you look at a dependency, think about what doors it’s trying to open in your system.

The paper's improvements: Tom: Okay, so we've looked at how they built that initial list of security-sensitive APIs based on documentation, CVEs, and CWEs. Now we need to talk about what they suggest we do next to actually make this useful in the real world.

Nadia: Right, the paper points toward a few specific improvements for making this methodology more practical for developers.

Elias: They suggest first an automated risk assessment system that takes a package call graph as input and compares it against others to show where the security API usage is similar or different across groups.

Nadia: That’s about automating the comparison we did manually; it lets tools do the heavy lifting of finding those patterns between packages.

Elias: They also propose something called context-sensitive permission setting, which means an AI system could actually inform tools like ZT DJAV A on what access controls to apply based on the security categories they identify, like FILESYSTEM or NETWORK.

Nadia: So it's not just listing the risk; it’s suggesting a way for systems to actually react and set permissions dynamically based on that data.

Elias: And then there's this idea of proactive vulnerability mitigation. If you map those sensitive APIs directly to CWEs and analyze how often they appear in vulnerable functions, you can get recommendations on mitigating risk faster if a specific vulnerability pops up in a dependency.

Nadia: That moves it from just being a list to being an actionable defense mechanism when things actually go wrong.

Elias: They also call for this open-source tool that takes the package call graph and generates those comparative visualizations, so developers don't have to do all that complex analysis themselves.

Nadia: That seems like a huge step toward making this accessible; instead of needing deep expertise in graph theory to figure out package interactions, there’s a visualization available.

Elias: And they mentioned integrating continuous security audits into the CI/CD pipelines, which means you can track those risky dependencies automatically over time instead of just checking them once at the start.

Nadia: So these improvements basically take their research from a theoretical study on API identification to a set of practical tools and processes for actual dependency management.

Elias: It’s about building an entire workflow around this data, not just generating a static report.

Nadia: And the core message remains that developers need to factor in both functionality and these specific security API calls when they are choosing what goes into their software stack.

Elias: So we’ve covered how they built the list, how it analyzes prevalence, and now how they suggest making it an active tool for development.

Nadia: Next up, we're going to look at the actual survey results—what developers are *actually* saying about using this information before we wrap up this deep dive into their proposed improvements.

Conclusion: Tom: So we've finished looking at how they built that initial list of security-sensitive APIs based on documentation, CVEs, and CWEs. Now we need to talk about what they suggest we do next to actually make this useful in the real world.

Nadia: Right, the paper points toward a few specific improvements for making this methodology more practical for developers.

Elias: They suggest first an automated risk assessment system that takes a package call graph as input and compares it against others to show where the security API usage is similar or different across groups.

Nadia: That’s about automating the comparison we did manually; it lets tools do the heavy lifting of finding those patterns between packages.

Elias: They also propose something called context-sensitive permission setting, which means an AI system could actually inform tools like ZT DJAV A on what access controls to apply based on the security categories they identify, like FILESYSTEM or NETWORK.

Nadia: So it's not just listing the risk; it’s suggesting a way for systems to actually react and set permissions dynamically based on that data.

Elias: And then there's this idea of proactive vulnerability mitigation. If you map those sensitive APIs directly to CWEs and analyze how often they appear in vulnerable functions, you can get recommendations on mitigating risk faster if a specific vulnerability pops up in a dependency.

Nadia: That moves it from just being a list to being an actionable defense mechanism when things actually go wrong.

Elias: They also call for this open-source tool that takes the package call graph and generates those comparative visualizations, so developers don't have to do all that complex analysis themselves.

Nadia: That seems like a huge step toward making this accessible; instead of needing deep expertise in graph theory to figure out package interactions, there’s a visualization available.

Elias: And they mentioned integrating continuous security audits into the CI/CD pipelines, which means you can track those risky dependencies automatically over time instead of just checking them once at the start.

Nadia: So these improvements basically take their research from a theoretical study on API identification to a set of practical tools and processes for actual dependency management.

Elias: It’s about building an entire workflow around this data, not just generating a static report.

Nadia: And the core message remains that developers need to factor in both functionality and these specific security API calls when they are choosing what goes into their software stack.

Elias: So we’ve covered how they built the list, how it analyzes prevalence, and now how they suggest making it an active tool for development.

Nadia: Next up, we're going to look at the actual survey results—what developers are *actually* saying about using this information before we wrap up this deep dive into their proposed improvements.

Elias: We'll keep going into the data and user perception now, Priya will weigh in on what all that analysis actually means for people making real-world decisions.