Skip to content
Justin Trugman & Babitha Singh

Artwork: Micha Huigen

Incorporating security in Enterprise DevOps workflows

How Caregility prepared for third-party security audits with GitHub Advanced Security.

Photo of Justin Trugman & Babitha Singh
Caregility logo

Justin Trugman & Babitha Singh // VP, Software Development & VP, DevOps, Caregility

The ReadME Project amplifies the voices of the open source community: the maintainers, developers, and teams whose contributions move the world forward every day.

At Caregility, we connect providers, clinicians, patients, interpreters, and family members, wherever they are. Whether we’re enabling virtual nursing, virtual observation, or virtual consultations, trust is paramount for our users. For companies in critical infrastructure areas like Caregility, third-party security audits can provide customers, investors, and internal stakeholders peace of mind. If bad actors were able to hack into our databases, compromise patient information, or otherwise exploit a code vulnerability, the results would be catastrophic. 

With GitHub Advanced Security and tools like Dependabot, CodeQL, and Secret Scanning, we were able to more easily prepare for a third-party audit and ensure the security of our code. When we first started incorporating GitHub Advanced Security into our GitHub Actions workflows, we were quickly approaching a third-party security audit. As we enabled each new service on GitHub Advanced Security, we began to realize the depth of the work that needed to be done. GitHub’s code scanning with CodeQL showed vulnerabilities and errors in our code; Secret Scanning highlighted improperly stored secrets and credentials; and Dependabot notified us of the vulnerabilities in our dependencies. It felt like opening a Pandora’s box with each service we enabled, and we had to devise a strategy for how to remediate newly discovered vulnerabilities quickly, before the audit started.  

We accomplished this by running GitHub Advanced Security features across our entire codebase for each language in use: Java, JavaScript, Python, Go, and Ruby. Once all of the vulnerabilities were discovered, we then included these services in a GitHub workflow to run continuously for repositories created after the initial run, to make a lasting change in our development processes that would prepare us for the future. From there, it was time to get to work prioritizing and remediating vulnerabilities and readying ourselves for the third-party audit. Since each tool can expose new vulnerabilities in your codebase, it can be overwhelming for anyone integrating GitHub Advanced Security for the first time. Here are some best-practices on how to organize your efforts toward tighter security, both short term and long term.

Inline1_Guide_Caregility Inline2_Guide_Caregility

In this Guide, you will learn:

  1. How to prioritize vulnerability remediation

  2. How to use search queries to monitor progress and address blockers

  3. How GitHub Advanced Security helps shift security left


Planning our approach 

To make a plan, we first had to understand the scope of the vulnerabilities we had to remediate. With over 100 services comprising the Caregility platform, each with its own repository, this was not a menial task. GitHub Advanced Security’s dashboard, however, offers a single pane of glass that showcases all detected vulnerabilities and a search field where we can enter queries to quickly find what we are looking for. In addition, the dashboard provides an easy way to monitor the team’s progress, which helps us to proactively address blockers as we encounter them.

Inline3_Guide_Caregility

Once you can visualize the state of security across your organization with the dashboard, you’ll need to prioritize which vulnerabilities you tackle first. This graphic below will help you organize an action plan to address your vulnerabilities, by repository priority and vulnerability severity. 

Inline4_Guide_Caregility

The approach we decided to take centered around two components: what stage of development the service with the affected code was in, and the severity of the vulnerabilities in the repositories. For the first component, we classified our services into three buckets: 

  1. Services currently in production. These are classified as the high-priority repositories for us to remediate, since the vulnerabilities would risk harm to our customers and platform. 

  2. Services close to production state and planned to be released soon. These are marked as lower priority than production services, but are still important to remediate, since unpatched vulnerabilities would expose customers when the service is released to production.  

  3. Internal tooling, automated tests, and in-progress prototypes. These are the lowest priority, since these services are internal-facing and are much less likely to be exposed and exploited.

Within each bucket we utilized the Common Vulnerability Scoring System (CVSS) classification given to the vulnerability. Working downwards from the production bucket to the prototype bucket, we remediated the vulnerabilities in descending order from critical to low severity. In order to monitor the team's progress, we made extensive use of search queries. Let’s break down how they work and how you can utilize them to monitor your team’s remediation progress. 

Using GitHub Advanced Security search queries 

GitHub Advanced Security search queries are pretty easy to use. They’re essentially just a key-value pair, where you pass in the selection, or sort type, and then the associated method of search, or sorting, that you want to utilize. The three queries we use most often are resolution: , repo: , and severity: .

Queries can be customized to show open and closed vulnerabilities, using is:open or is:closed. And the repo: prefix allows us to specify the specific repository to query. For example, the query below shows the open vulnerabilities in our front-end authentication service.

is:open repo:auth_service_frontend

We are also able to find the vulnerabilities that were closed previously for reasons that would not be acceptable for the third-party audit. For example, some vulnerabilities may have been closed because we didn’t have the bandwidth to deal with them at the time, or because they were seen as a tolerable risk. By tailoring the query to search for “no-bandwidth” and “tolerable-risk,” we can reopen those vulnerability alerts and address them as needed.

resolution:no-bandwidth resolution:tolerable-risk

Finally, we are then able to combine a few different queries to come up with a list of vulnerabilities we need to remediate. By searching for open vulnerabilities in specific repositories sorted by severity, we now have a list of vulnerabilities that need remediation in order of severity.

is:open repo:[REPO_NAMES] sort:severity 

These queries allow us to easily monitor how far along we are within each bucket of repositories, while also showing the severity of the remaining vulnerabilities within each bucket. These search queries give us the information we need for short weekly meetings, where we review the results and get feedback from the team about their progress and any blockers. 

Inline5_Guide_Caregility

The outcome

By preparing for the third-party audit using GitHub Advanced Security, we not only increased the security posture of Caregility by remediating over a thousand vulnerabilities, but our audit results came back cleaner than they would have otherwise, since we were able to remediate so many vulnerabilities beforehand. GitHub Advanced Security helped us to protect our customers and users from security breaches, preserving their trust in our products. And by spending time preparing for our audit, we were rewarded with a cleaner security audit report, which is a crucial outcome for our customers and internal stakeholders, as it shows how we have minimized the security risk to the business.

Moving forward with security in mind

GitHub Advanced Security not only helped us to prepare for our third-party audit, it also made us realize that we needed to tightly weave security into our development process moving forward. When we provisioned the tooling for the audit preparation, we also configured it in our GitHub Actions pipelines to run on every pull request. This allows developers to get immediate and continuous feedback on the security stance of their code. It also allows us to add security directly to our code review process, enable branch protection policies so secrets don’t leak into production code, and ensure other potential vulnerabilities are found early. By shifting our security left, we have significantly derisked the effect code vulnerabilities can have on Caregility.  

Securing enterprise platforms

Ensuring the security of your codebase is an unending process, but GitHub Advanced Security helps to notify you of vulnerabilities as they’re introduced, eliminating vulnerabilities from your codebase and mitigating risk to your organization. We not only decreased our risk of a security breach, but we also successfully prepared for our third-party audit, solidifying the trust of our customers, investors, and internal stakeholders. After our experience, we recommend that companies prioritize security and adopt tooling like GitHub Advanced Security into their development process. By prioritizing security during the development process, companies can avoid potential problems down the road, handling vulnerabilities as they are introduced rather than all at once.   

Caregility is a virtual healthcare platform that provides 24/7, secure, HIPAA-compliant access to two-way audio and video communication and clinical workflow integrations that span inpatient and outpatient telemedicine settings.

More stories

In Scorecard we trust

Naveen Srinivasan & Brian Russell // OpenSSF

Scaling MLOps education

Noah Gift // Pragmatic AI Labs

About The
ReadME Project

Coding is usually seen as a solitary activity, but it’s actually the world’s largest community effort led by open source maintainers, contributors, and teams. These unsung heroes put in long hours to build software, fix issues, field questions, and manage communities.

The ReadME Project is part of GitHub’s ongoing effort to amplify the voices of the developer community. It’s an evolving space to engage with the community and explore the stories, challenges, technology, and culture that surround the world of open source.

Follow us:

Nominate a developer

Nominate inspiring developers and projects you think we should feature in The ReadME Project.

Support the community

Recognize developers working behind the scenes and help open source projects get the resources they need.