EdgeBit’s Dependency Autofix works by understanding how your application code calls into the various direct and transitive dependencies it requires. Your app’s call graph and other reachability metadata is used as an input for determining when and how to update your dependencies.
The result is a set of proposals for dependencies to update. Based on your perferences, proposals may be analysis only, opened as Pull Requests or send for review to the engineers that are determined to be the experts within your organization for using a certain dependency.
When learning about Dependency Autofix, you may have questions like:
We’ll walk through the life cycle of EdgeBit making a code proposal to answer these questions.
EdgeBit always uses a short-lived, ephemeral VM for processing your source code. These machines are never re-used and only exist for the lifespan of the analysis and proposal generation process — often just minutes.
Each VM is handed a unqiue set of short-lived or one-time-use credentials for executing the job at hand. Analysis steps are further isolated from each other and only the most minimal set of network or disk access required to execute the step.
After the code analysis is complete, the VM and any customer source code is destroyed. Analysis results are retained, which includes function names, function call graphs, file paths, library names and versions, and similar data. See the privacy policy for more details.
EdgeBit staff have no access to the machine and no access/SSH credentials are configured.
EdgeBit strongly believes in safeguarding our customer’s code and these efforts perfectly overlap with our need to protect EdgeBit from handling untrusted code as required by the analysis process.
Dependency Autofix uses an understanding of which dependencies you have installed, how your application code uses them, and which dependencies have updates available in order to make a decision whether to upgrade a dependency. You may see this process called static analysis and reachability analysis.
Vulnerability data and the language ecosystem’s dependency graph are also used for prioritiziation. At this point, no AI has entered the picture, so there is no impact from hallucination nor an ability for a rogue selection to be caused by AI.
From your app’s call graph and an updated set of dependency code, we can make a very strong determination of the impact of an upgrade. AI is used to augment this determination by parsing how specific functions have changed and commits tied to those changes.
Using Dependency Autofix will accelerate your team’s ability to remediate vulnerabilities and stay up-to-date on dependency upgrades over time.
How EdgeBit’s code proposals are applied to your application code should be determined by your engineering culture and your change management rules within your compliance program.
It’s common to require human code review for in-scope applications, which typically uses one of these workflows:
mainmainEach of these workflows results an opportunity for code review while reducing risk and overhead related to researching the dependency version to pick, whether it’s compatible or not, and the work to make the update itself.
Sophisticated customers may have automated merge criteria for dependency updates or container rebuilds, which EdgeBit can meet and execute merges directly to main.
EdgeBit automatically tags dependency updates seemed to have very very low risk with a no impact tag, which can be used to gate automatic merges to main.
We recommend adding language to your change management policy to allow trusted tools, such as EdgeBit, to automatically merge certain types of code changes:
Automated software updates are produced by trusted tools which propose software updates, run analysis, and calculate the risk related to applying the update. Updates determined to have no adverse impact on the codebase are given a “no impact” tag.
Pull Requests with the “no-impact” tag are considered approved and may be merged once other required CI steps pass. The Tag Protection rules enforce that only trusted tools, not humans, can add this tag to Pull Requests.
The list of trusted tools is maintained by the CTO and engineering leadership.
This discussion is nuanced, and we’re happy to chat more with your team.
