I went to school in Ukraine and it was heavy on English, so I had up to seven hours of English a week. By the time I finished school, I got to a pretty decent level, which helps a lot in the industry that I’m working in. I then entered university in Ukraine to study Computer Science, but after studying here for two years, it wasn’t as good as I had hoped. I decided to move to Warsaw, Poland and continued my studies there. With one year left to study, I found a job working as a junior software engineer. Initially, I was hired to work on some insurance stuff. They were using software called Guidewire. However, I was lucky enough that there was no Guidewire project for me.

As a result, I landed on a project with a heavy Java stack, using Java 8, Spring, Hibernate on the back end, and AngularJS and Angular on the front end. That really helped a lot and I feel like I won a lottery there because that’s how I developed most of my Java and JavaScript skills. I worked there for three years while I finished university, staying in Poland. Then Covid happened and for personal reasons, I eventually moved back to Ukraine. I had to leave my job since they did not offer remote work, but I found a new one at CloudBees. Initially there was this little project where we were cleaning up some security technical debt with some other folks. As my project was coming to an end, we were asked where we wanted to go, and I had a preference for security. This is how I ended up in the Jenkins security team at CloudBees, and that’s how I gained most of the Jenkins skills that I have right now. This also helped a lot when working on the recent CSP project in Jenkins.

It’s probably worth mentioning that I used Jenkins in my first job. That was my initial exposure to Jenkins, despite not using it too heavily. We only had CI at the time, as we were using Gerrit for code review and Jenkins for builds. I was just a basic user checking build logs and performing more basic actions. But there were some micro projects where I had to do performance tests for software that we were building. I used Jenkins for it, despite not being sure it was optimal for my purposes, but that’s one notable thing I can think of.

Other than that, I wasn’t necessarily a heavy user of Jenkins. Most of my work has been done on Jenkins instead of through Jenkins. It’s not like I need Jenkins during my daily life outside of the job. I’m trying to keep the balance between spending time in front of a PC doing work stuff and my spare time. So, I’m just trying to relax a bit in my spare time and keep work at work.

At the time, there was one colleague who is also a member of the community, Damian Szczepanik. He sat right behind me and he was our de-facto admin since he was doing most of the admin tasks for our project. I was interested, but I wasn’t necessarily "allowed" to enter that area because I had other things to work on. It was still attractive to me, but I didn’t get to work on Jenkins while I was working at my original company. However, when I was changing jobs I had an opportunity to interview with someone who explained that the work would be for Jenkins, and specifically security, which instantly sold me on the job. I was never a big fan of enterprise businesses like insurance or banking, it’s always been a little boring for me. I’m more a fan of heavier technical things like Jenkins and other more developer-focused work. So, it was easy for me to get excited when I heard they’re hiring for a Jenkins project.

The CSP work was fairly narrow as it was focused on enhancing the Jenkins CSP. There are several archetypes of issues and I was familiar with how you approach a certain problem or how you solve it because we had some initiatives when I was originally working in the Jenkins security team. We were working on CSP stuff in Jenkins core, so we weren’t touching plugins, but most of the issues that I have faced during the CSP project I was already familiar with how to approach them. When it comes to the Jenkins security team, the work that I was doing was part of the overall responsibilities of the team such as code review, fixing vulnerabilities in Jenkins core, and security advisories just to name a few.

In regards to the challenges of the CSP project, it was not due to Jenkins or CSP, but JavaScript being JavaScript. There were some subtle, but very technical JavaScript caveats that needed to be addressed. Those problems were partially due to users not willing to leverage what Jenkins already has. For instance, it has the Jelly engine for views and people were trying to add JavaScript frameworks, such as React or Angular to that. The custom implementations contributed to some issues in their own way because those implementations were not fitting into the archetypes of issues that we were already familiar with and knew how to solve. So we had to figure out the framework first and see if there was a mechanism that allows you to enforce CSP. Then we had to try using it and depending on how old the technology was, the mechanism could exist or not exist. From there, you had to cook up something different to come up with a solution.

I think extensibility is the real power of Jenkins. If something doesn’t exist, you can either look at the plugin ecosystem or in the worst case, you can just write it yourself. It’s great because you can basically use Jenkins for whatever task you can come up with. Taking it one step further, if you want to automate the task you can most likely do it in Jenkins if you spend enough time. For instance, performance tests are not a very regular use case as far as I’m concerned, as most people use it to build software or publish, but in my first job we implemented performance tests. This is an example of a quirky way to use Jenkins.

While fixing CSP issues, we would also fix any core vulnerabilities that are out there. For example, some vulnerabilities are caused by incorrect usage of JavaScript (due to developers cutting corners or being unaware). This could be something like usage of eval or using inline scripts on HTML elements. These incorrect usages create XSS sinks if unsanitized user input is supplied to them. If CSP is set with a policy that is strict enough, those vulnerabilities wouldn’t exist because the scripts wouldn’t run.

Read a lot of code and try to really understand what the code is doing. If you want to add some functionality or change an existing functionality, just read a lot. Really try to understand how it may impact extensibility. This understanding is crucial when contributing to a project because there is lots of history behind the code.