Make Developers' Lives Easier with Endor Labs & GitHub Advanced Security
Developers are bombarded with information every day. Constant context switching and information overload are among the biggest barriers to productivity. There are simply too many demands for their attention. One day the sales team will understand. Right?
Developers are bombarded with information every day. Constant context switching and information overload are among the biggest barriers to productivity. There are simply too many demands for their attention. One day the sales team will understand. Right?
Developers are bombarded with information every day. Constant context switching and information overload are among the biggest barriers to productivity. There are simply too many demands for their attention. One day the sales team will understand. Right?
Developers are bombarded with information every day. Constant context switching and information overload are among the biggest barriers to productivity. There are simply too many demands for their attention. One day the sales team will understand. Right?
Developers are bombarded with information every day. Constant context switching and information overload are among the biggest barriers to productivity. There are simply too many demands for their attention. One day the sales team will understand. Right?
.png)
GitHub Advanced Security together with Endor Labs has one primary goal - make developers' lives easier. Developers can now use GitHub Advanced Security and Endor Labs without having to leave GitHub to triage security and operational issues with their projects.
How Do GitHub Advanced Security and Endor Labs make for a better OSS risk management program?
In software development, developers often rely on reusable code components, or dependencies, to speed up their development process. However, managing these dependencies can pose a risk to the security of the software depending on many factors surrounding how they are used.
GitHub Advanced Security provides a foundation for risk management by using Dependabot to identify and suggest updates to dependencies in the software manifest files and lockfiles used by package managers. This approach helps reduce the risk of using outdated or vulnerable dependencies, providing a seamless and developer-centric experience.
However, this approach only lays the foundation for a mature risk management program. To build on this foundation, it is essential to understand the process of dependency resolution.
What is dependency resolution?
Dependency resolution is the process by which the appropriate versions of dependencies are identified and conflicts are resolved during a software build process. When developers declare unresolved dependencies in their manifest files, they rely on a build tool or package manager to resolve these dependencies and select the appropriate versions of software components. This process involves identifying and resolving not only direct dependencies but also their transitive dependencies, which are the dependencies of the direct dependencies.
Lets say I’m developing the package “nice-ewok” and want to use the software package axios, which helps javascript developers make http requests. I would run the command:
npm install axios --save
This command then declares an unresolved dependency in my package.json as shown below.
The "^" character in front of the version number signifies that the project can use any major version of the "axios" library that is compatible with version 1.4.0 or higher, but lower than version 2.0.0. But how does your software select the right version? What happens when your dependencies also depend on other software? This is solved by a process known as dependency resolution. The requested dependencies in the above manifest file are prior to dependency resolution, which is why they are called unresolved.
When dependencies are resolved, the appropriate versions of unresolved dependencies are selected by the build tool or package manager, which become direct dependencies. Each direct dependency may have used other software packages as dependencies and these must be resolved as well. These become transitive dependencies. Since software re-use is so prevalent in modern architectures, the vast majority of known vulnerabilities in software components come from transitive dependencies.
Mature and cost effective programs with integrated software delivery and security programs need to operate on both pre and post build information because of the dependency resolution process to make informed risk management decisions.
How does Endor Labs build on Dependabot's foundation?
Managing software dependencies can be a daunting task and organizations who are on their journey to get clean and stay clean may feel overwhelmed on what issues to do first. Endor Labs helps teams on their journey by providing them with information on if a software component is reachable and through deep security research also can provide visibility into if a function call associated with a known vulnerability is reachable. If addressing an issue may pose a challenge, Endor Labs helps teams to prioritize these by helping them understand where they should focus their efforts.
Organizations who need to systematically improve their security posture and reduce the cost of their security program over time can use Endor Labs to identify dependencies that are unused or unmaintained.
Dependabot lays the foundation for teams that integrate application security and software delivery by operating on pre-build information to help organizations identify outdated and vulnerable code. With Endor Labs, GitHub Advanced Security customers gain enhanced levels of visibility across their environment and context to help them prioritize their issues more effectively.
Organizations are then able to use this visibility to set DevOps Governance policy based on their software risk tolerance within Endor Labs. This policy can then fail scans. This policy isn’t just for what you build your software with but how you build it. Branch protection policy and best practices can be set in Endor Labs to provide teams complete visibility into their repositories security posture. With Endor Labs and GitHub Advanced Security, you can manage both what you build and how you build it.
The outcome is a complete and developer-friendly DevOps Governance workflow.
So how would you use Endor Labs with GitHub Advanced Security?
To use Endor Labs with GitHub Advanced Security, you can leverage the integration provided by Endor Labs through GitHub Actions workflows and reporting in the GitHub UI. A typical GitHub Action workflow using the Endor Labs GitHub action might include the following steps:
- Checkout the repository
- Setup Java tools
- Build the software package
- Scan the software package with Endor Labs
- Upload the scan findings to GitHub in SARIF format
A full GitHub Actions workflow file might look like this:
The first three steps are standard in any software build process. They involve checking out the source code, setting up the tools required for the build process, and running the build process itself. In this example, the build process is performed by running the command mvn clean install.
The next step is to scan the software package using Endor Labs. We test the software package on every commit in a pull request, and monitor every push event to the default branch. Endor Labs allows you to set organizational governance policies to fail the scan or warn developers about any issues in the build that may deviate from organizational policy.
Endor Labs uses keyless authentication with your GitHub ID token, so there's no need to manage secrets, which saves developers the hassle of secrets management and improves security.
When running the Endor Labs scan, you need to specify the tenant namespace within Endor Labs, the output format for any findings, and the name of the file that you will use later to upload the findings to the GitHub UI. For example, you can define two separate workflows for scanning pull requests and push events, respectively, as shown below. On push events we continuously monitor for new issues and on pull requests events we perform a point in time test on the software packages.
Finally, you need to upload the findings to GitHub so that developers can triage operational and security risks directly in GitHub with the context of how the software uses the dependency in the tags. By using the github/codeql-action/upload-sarif action, you can easily upload the scan findings to GitHub in SARIF format, as shown below:
By uploading the findings to GitHub developers to triage operational and security risk directly in GitHub with the context of how the software uses the dependency in the tags. We can see here that the vulnerable function associated with this vulnerability is reachable in the code base and therefore should be prioritized.
Organizations can then use this process to create governance policy for their software and break builds when security or operational risk falls outside of their policy or risk tolerance. Scans can be failed so developers have a continuous feedback loop throughout the development process.
