Our experience in this space tells us there are basically two ways to approach the problem of managing open source software (OSS) components in a continuous integration (CI) workflow. We’ll call these two ways 1) “repository-centric” and 2) “build-centric.”
Both approaches have merits and drawbacks; the purpose of this post is to describe the use cases and make recommendations about best practices in given situations.
Managing Access with the Binary Repository
The screen capture below shows how virtual repositories can be daisy-chained together to segregate approved third-party artifacts from those that have not yet been approved. It also differentiates those available locally from those available externally.
As you can see, this is our own Artifactory instance, which we set up with the intention of managing compliance of third party libraries via access.
With this scheme, you can control access to binary libraries tightly; by moving anything deemed unsuitable out of the approved repository, while also preventing access to outside resources (Maven Central, for example).
Given the proper set of available APIs on both sides (Hub and Artifactory), you can accomplish promotion, demotion, and removal of unsuitable libraries; with this scheme it’s possible to prevent non-compliant artifacts from ever being created at all.
The main challenges inherent in this approach are:
- This scheme mandates a very complex web of repositories and virtual repositories be created and maintained on a per-project (that is, per application) basis because different rules apply at this level.
For example, GPL components are not permitted in apps we distribute externally, but are allowed in our internal tools, so these each require their own repos with logic baked into build scripts to reference the proper repos.
Depending on how the projects are constructed and built, it’s even possible that different repos will be required based on specific usage (that is, “join-level”) of components within the project. - Managing components this way also has dramatic repercussions with respect to how builds fail. If components are not available due to policy infractions, the only message shown to end users is “dependency could not be resolved.”
Further information about the specific reason for the failure cannot be made available to the developers or builders. - Because the build could not run, artifacts were not created and scanned — there is not even a Hub project for users to investigate issues, override the policy decision if desired, or adjust the matched component (in the unlikely event that we didn’t get it right
![😉]()
).
).Managing Compliance with Build Tools
The screen capture below demonstrates how you can leverage a “continuous integration pipeline” to provide fine-grained control over each phase of the software development life cycle (SDLC).
Note that in our particular case, the “Hubv2.5.x-scanWithHub” build is only run nightly and never actually blocks the CI process, but we could easily set it up to do so if desired.
The various stages of our build lifecycle are (I will shorten the names for simplicity):
wellspring – this is the job that pulls new changes from our git source control system
ui – this job builds the ui client package
doc – the doc is build as independently deployable artifact
back end compile – the Java code is built here, libraries which we depend on are linked in (directly from the build system’s cached copies unless a new library is requested)
Although not called out specifically in the name, unit tests are also run as part of this build
integration test – integration tests are run here
functional tests – tests that require external systems are run in this phase
packaging – if we’ve gotten this far, we have deemed the artifact worthy of being pushed back to the snapshot repository so we can run our update and installer testing against it
deployment – test that the artifact can be redeployed onto a running Hub system
REST API tests – once the new artifact has been deployed to the test system, we can run various tests against it, in this case the test suite exercising our REST endpoints.
selenium – not depicted in the screen capture, but in newer versions of the product, we have a build that runs selenium tests against the running system.
This approach is friendlier for developers and build engineers:
“Continuous is better for me because the earlier the detection of security vulnerabilities happens, the better. That way, you can easily a) track the commit that made the change and fix it, or b) revert the commit without having to revert stacked commits.”
— Bob Lloyd, BDS Build Infrastructure Architect
The nice thing about how this process is designed is the flexibility it affords us, especially with regard to our continuous development and testing efforts.
Managing Open Source Software Usage
Builds can pass or fail at any step along the way, depending on where we want to put the “circuit breakers.” For example, we won’t let the build move forward if unit or integration or tests fail (this indicates that the product is likely not worth our QA team’s time), but we have broken out the functional tests into a different stream because they have a higher instance of failure due to dependence on external dependencies.
Additionally, when policy build failures occur, we can provide meaningful error messages to developers and managers that will help quickly them understand the specifics of the problem.
Being able to cache artifacts for longer periods (without having to call the repo) in the build environment means faster build times.
Finally, Repository layout can be clean and simple, and build scripts don’t need to hard code lots of pointers in to different repo locations.
The challenges with using only this approach is because you can complete some builds containing potentially unsuitable artifacts, there is a non-zero risk that these could end up moving farther downstream.
CONCLUSIONS
While we tend to prefer a more continuous approach to compliance in our Engineering organization, there are certainly cases where it’s best to “abolish” artifacts from the repository entirely, therefore it is our recommendation that you apply a hybrid solution, erring towards one side or the other according to your view of trading off efficiency in development with their general risk tolerance.
The post When Managing Open Source Software Usage, Build Jobs Make Life Safer & Easier appeared first on Open Source Delivers.