Jenkins is the way to DevSecOps

Cybersecurity CI/CD

Submitted By Jenkins User Canux Cheng
A cumbersome legacy process for building, testing and releasing software is a huge challenge for a global cybersecurity company that has to stay ahead of hackers, fraudsters and trends in cybercrime. 
Organization: Cybersecurity solutions for enterprises, governments and SMBs worldwide
Industries: Network Security
Programming Languages: C/C++, Node.js, Python, Golang
Version Control Systems: GitLab
Community Support: Jenkins.io websites & blogs, Networking at Jenkins event

Creating a flexible CI/CD chain to meet the development needs in the field of cybersecurity.

Background:  This international cybersecurity company serves enterprise, governments and small businesses worldwide. The developer team always had too many balls in the air with multiple projects happening simultaneously. These included virtualization tools like kernel-based virtual machines (KVM) IKVM and Oracle’s open source VirtualBox. The interdependencies between  projects were applause-worthy. However, nearly everything was managed via a cron job,  a time-based scheduler in a Unix-like computer operating system that would program jobs to run periodically at fixed times, dates, or intervals. 

Goals:  Move everything to Jenkins instead of relying on cron jobs and scripts.

"Now, everyone has a Jenkins account and everything can be visible on the Jenkins UI. It’s like having a DevSecOps Hub."
image— Canux Cheng, Software Engineer

Solution & Results:  The main target was to have an automated CI/CD chain and with a few steps using Jenkins, and we got what we wanted. Each project would replace cron job scripts and makefile with a Jenkinsfile, and we used the Jenkins plugin API or an http-based API instead of having to invoke a shell command. 

Then we had another challenge: moving all code to GitLab.  

To do so, our  developers commit code to GitLab which triggers Jenkins to invoke a Jenkinsfile. We built the code on the container using Python/C++ for the back-end and node.js on the front end, allowing us to push to Harbor, a private open source container image registry. Now we can pull new images and deploy to a test bed. Once done, we can then launch an automation test, and if the test passes, the PM can release the latest version.

There were some basic steps we had to follow, including:

  • How to convince developer use Jenkins:

    • We created a Jenkinsfile for each project

    • We deleted Makefile and cron job scripts

    • We gave developers no choice

  • How to notify users about build/test result:

    • We used Slack and email

  • How to integrate with GitLab:

    • We used the Jenkins-GitLab-plugin

  • How to integrate with container:

    • Again, we used the Jenkins-GitLab-plugin

  • How to monitor Jenkins:

    • We rely on Prometheus in Grafana

Now, everyone has a Jenkins account and everything can be visible on the Jenkins UI. It’s like having a DevSecOps Hub. And we got excellent results, including:

  • everything is triggered automatically

  • every developer/QA knows exactly what is happening with their code, and in real time

  • integration with GitLab makes code management easier

  • integration with a private registry makes image management easier

  • Jenkins status is always visible in case a server or service goes down