Has anyone ever asked you where all of your applications were located; and your response was “Somewhere in GitHub?” We know that feeling too.
That feeling is exactly why we’re rolling out a new experience to quickly onboard applications from a source control repository such as GitHub, GitLab, and Bitbucket to Nexus Lifecycle. This simplifies adoption and implementation across your development org, drastically reducing the time it takes you to start remediating issues.
We’ve also created an instant risk profile that’s automatically produced when you onboard and scan your applications. The profile helps understand all of the risk across your organization.
Image: Importing applications from Github to Nexus Lifecycle
Image: Reviewing the Scan Results from Nexus Lifecycle for associated Risk
We finish off this rollout with automated review on every Pull/Merge Request that is opened to help developers catch issues early, choose better components, and avoid rework later. We do all of this without any configuration other than pointing Nexus Lifecycle to their SCM.
Why does this matter?
Because we believe in taking away stress not adding to it. We know that software adoption is hard. Solutions need to be easy to use and simple to deploy across the organization or their impacts will be limited.We also know that new tools that aren’t easy to use or create a lot of noise and friction will be ignored by most developers.
Adoption of Nexus Lifecycle is now seamless and scalable across your development organization, with a fast, simple way to find and onboard applications where your code already exists - in GitHub, GitLab, and Atlassian Bitbucket. Security champions can understand their level of risk immediately, and development teams can start remediating violations right away, drastically decreasing mean time to resolution (MTTR). It’s a win-win.
Ongoing remediation efforts are enhanced by evaluating code directly in the Source Control without the need for additional tools or integrations. Nexus Lifecycle now participates in the pull request process by scanning every new pull request to give developers early feedback on things like component choice, breaking changes, open source vulnerabilities, or policy violations. You can configure your CI/CD to run an even more in-depth scan at build time for a greater level of security before releasing to production.