What’s New in OpenContext: Context Details Tab Featuring Dependabot Data

Today, OpenContext co-founders, Brian Walter (CEO) and Alice Chen (CTO), are sharing how we’re helping organizations achieve true DevSecOps by being on the same page—literally—and how powerful that can be.

This article covers the following features OpenContext recently released:

• Context Details Tab
• Dependabot Integration

Let’s dive in to hear what our co-founders have to say!

Reduce Tension Across DevSecOps Teams by Having Conversations Around Shared Context

DevOps and DevSecOps are structural team concepts born out of a desire to get along, but often, forcing these roles under one roof leads to tense desk drive bys and even nerve-wracking board rooms. This is often the case with kumbaya moments that start and end with a lack of consensus.

And that’s because there are many ways to slice the pieces of a pie based on a plethora of priorities. It’s never about who’s right or wrong, but it almost always feels that way.

But if there’s one thing the three founders of OpenContext have all been able to do in their own unique ways, it’s wrap their arms around all aspects of tech to create bridges both between teams and across company-wide hurdles.

What all three of them agree on is that it’s about starting out looking at the same data and creating consensus before branching off to save the day with each parties’ strengths. And that’s how the Context Details Tab (among many other OpenContext features) was born:

Walk us through the Context Details Tab view and what you're most excited about.

Alice: The Context Details tab can be found on any code component’s page. So, if you have a code component you're interested in, and especially if it's of a type repository, you can go view the component in OpenContext. 

Each component page has three tabs: 

1. A context tab, which is the general context of that particular code component. 
2. A GitHub Actions tab
3. And then, finally, it'll have the Context Details tab.

Then, on the Context Details Tab, you’ll see cards for: 

1. Owners
2. Code Paths (If it has code paths—not everything has code paths), 
3. Summary Card with how many sub components are linked to this particular component
4. Dependencies
5. Repository Statistics (such as languages used, recent releases, contributors all linked to GitHub)
6. Vulnerability Alerts - from our new Dependabot integration!

This gives you a very high level summary of how many things that component touches, essentially. And from that, you can get a good idea of the complexity of what you have to keep track of if you're going to make major changes or if you need to do things cross functionally. 

From there, you should be able to have better judgment about how to communicate. What you need to worry or talk about. If you have a whole bunch of dependencies, it's very highly probable, you're gonna break something if you don’t talk to all the other people or contributors involved.

This is why we include both contributors and owners which is not quite the same. Contributors could be people that have worked on the project previously but they're not assigned to the project. There's often people that like to hop in to help here and there for different things. And those will show up as contributors, but not in the owners section of things,

Brian: Which is important, because those contributors might have context that even an owner isn't totally aware of—especially given that they might be contributing because of something very specific.

These are often your hidden subject matter experts.

Where does the info for each card on the Context Details Tab come from?

Alice: Almost every card gets information just from GitHub. However, the components statistics summary comes from the backend of OpenContext’s graph. 

This graph does two things: it graphs the relationship and summarizes the number of relationships it has.

It does this because this is usually what we, as humans, lose track of. Because there's way too many of them, right? And it's ever-changing. So, this gives you a good snapshot view of what this repository is, has it made any deployments, how many dependencies or intertwining things that it has in relation to other things. And then who to contact if you need to actually fix something. And then a snapshot of your top 20 or so security vulnerabilities with Dependabot!

Yes! Can you share how the Dependabot integration works and how open context users can get the most out of this data?

Alice: The Dependabot integration comes from GitHub. So there's nothing extra an OpenContext user needs to do to get it, except for the fact that they do have to have Dependabot actually enabled in the repositories to report the vulnerabilities and stuff like that. 

As long as the repository has that enabled, then we will be able to fetch information about vulnerabilities about the repository. And that information is on our Context Details page at the bottom. 

This shows things like when the vulnerability was found by GitHub, the severity, summary, path, etc.. It knows which file actually has this issue and whatnot so that's a path. And if your repository uses a supported package manager like NPM it'll tell you what packages are affected, version affected and potentially the fixed version. 

We will fetch approximately the top 20 vulnerabilities. Giving you a decent idea of the recent and high vulnerabilities you have in your repository.

How do you see the Context Details Tab playing into the day to day life? When would this have come in handy in your previous roles in tech?

Alice: Well, when you're sprint planning, you would see this as pretty useful. Imagine if you're going to make a major feature or API change, there’s usually a lot of things that get forgotten.

Those types of changes that you kind of know in the back of your head, like who you need to talk to, but you will likely forget if you don't do it right away. Or if you don’t make changes like that as often, you might not know who or what team you need to go to, right?

Melissa: So it just becomes a general shout out to the void or another calendar invite with too many people on it.

Alice: Yes, that's exactly what happens. So now, you can be more proactive. 

For example, during sprint planning, you can go look at the Context Details Tab to see the component dependencies and that it’s dependent on these other things. Now, you can go look and see who owns it and if they're making changes to their repository. 

And then, in more practical terms, oftentimes operations or security gets called for an incident and it would just be easy and good to know what's happening in a code repository.

They don't necessarily need to know exactly what commits are happening, but what are the vulnerabilities or are we seeing a pattern across multiple repositories? 

And with Dependabot right there, developers who might normally not pay that much attention to what the Dependabot says, can at least look at it or show it to Security and Ops. And from there, at least now they can all be talking the same language.

Melissa: Yeah. And this is where an alert like maybe you're working in GitHub, you see the alert, and you have that moment of, well, I can't know where to go with this information. It doesn't seem great, but I don't know exactly what to do with it, I guess. You know, but in this scenario, now, you can go into OpenContext, the what to do as any next step, versus just not doing anything or calling into the void.

Brian: Attaching those vulnerabilities as the example right? You might have a code component that's vulnerable to some form of an exploit that needs to be updated, but you might have dependencies that crossed the team boundaries? Right. 

And so particularly with some of our customers that are in these large monorepo environments where they've got a lot of teams working inside the same codebase, it wouldn't be safe for somebody to just simply update a library without discussing the implications of that potentially with multiple teams. 

And how would you know without a dependency graph exactly who's going to care if you upgrade that particular library? 

That's one of the very core functions of our dependency graph and attaching it to vulnerability status.