This summer, I had the exciting opportunity to work as a Software Engineer Summer Worker at Broadcom’s Plano, TX office. It was a hands-on, immersive experience that gave me invaluable exposure to real-world software development challenges. Not only did I sharpen my technical skills and broaden my understanding of industry best practices, but I also made lasting connections with a great team.
The Problem: Manual, Time-Consuming Vulnerability Triage
At the core of my time with Broadcom this summer was a project focused on automating the triage of security vulnerabilities flagged in third-party components used in Broadcom’s applications.
For context, the Mainframe Software Division uses BlackDuck, a tool for scanning and reporting security, license, and operational violations in open-source dependencies. In today’s tech landscape, where open-source software is ubiquitous, ensuring the integrity and compliance of those components is critical.
However, the existing workflow was not as efficient as it could have been. Each week, team members had to spend numerous hours manually reviewing and verifying vulnerabilities—often needing to cross-reference Red Hat base images and BlackDuck scan reports. Due to inconsistent results and false positives between different services, this process could take hours or even days depending on the volume of reported vulnerabilities. It involved clicking through various dashboards and recording each finding manually.
The old process was as follows:
Clearly, this process was in desperate need of automation. The new process is outlined below:
The Solution: Automating with a Jenkins Pipeline
My project aimed to automate and streamline this time-consuming process—reducing manual work, improving accuracy, and giving the team faster insights.
I designed the solution collaboratively with input from the team to ensure it met real use cases. After getting feedback and refining the idea, I developed the project using Java and Spring Boot, initially running locally and later integrating it into a Jenkins pipeline for broader accessibility.
As the project progressed, the tool evolved significantly. Early iterations lacked features like column headers or readable formatting in the generated output, which caused usability issues. Thanks to team feedback, these problems were quickly addressed.
Here are a few examples:
One major challenge came when we decided to introduce Trivy as a second verification source to double-check results from Red Hat. Unlike Red Hat’s API, Trivy required scanning the Docker image directly, which necessitated a significant refactor of the codebase and deeper integration with Jenkins.
This led me to work with Groovy, the scripting language used in Jenkinsfiles. It was both a technical challenge and a great opportunity to learn more about how CI/CD pipelines work behind the scenes.
In the end, the tool now outputs a concise, easy-to-read CSV file that the team can review quickly, enabling more informed decisions and helping them communicate findings more effectively to the Dev Council. Most importantly, it significantly cut down the number of steps—and the effort—required to complete the same task. My tool reduces the amount of time spent on the same task by over 95%.
What I Learned
This summer was incredibly rewarding—not just because of the final product, but because of the sheer amount I learned along the way. While it's hard to summarize everything, here are some key takeaways:
-
Mainframe Structure + WatchTower™. Before my experience this summer, I didn’t know much about Mainframe systems or WatchTower (WT). Learning their structure and importance helped me better understand the broader purpose of my project and how the team operates daily.
-
Images and Containers. Thanks to several helpful diagrams and explanations, I now understand how containers are used throughout WT and how essential they are for efficient deployment and scanning.
-
Using New Tools and Frameworks. I built an entire Jenkins pipeline from scratch, which was both time-intensive and gratifying. I also learned how to configure and deploy applications using Spring Boot, diving into different runtime settings and dependencies. These are just two of many tools I gained experience with.
-
Agile in Practice. I had studied Agile before, but this was my first time actually living it. Experiencing daily stand-ups, sprint planning, and quick feedback cycles made me appreciate how Agile drives collaboration and iteration in a real-world environment.
-
Debugging (The Right Way). In school, debugging usually means trial and error. At Broadcom, I learned how to debug methodically and effectively, especially after dealing with many failed Jenkins runs. It taught me to trace issues, understand logs, and solve problems at the root level.
-
Asking for Help. This might sound obvious, but learning to ask for help isn’t always easy. Thankfully, the team at Broadcom was incredibly supportive. Everyone had so much experience and was always willing to offer guidance. It made asking questions feel natural instead of intimidating.
Final Thoughts
As of now, my tool is being tested and gradually integrated into daily team use—which is incredibly exciting to see. The project gave me a well-rounded education in software development—from writing secure, maintainable code to understanding licensing nuances and automating DevOps workflows.
Most importantly, I’m grateful for the opportunity. I got to work on something real and meaningful while surrounded by brilliant and supportive people.
Huge thanks to my team (who patiently answered my many questions), and special shout-outs to my manager and assigned buddy for making my transition smooth and welcoming from day one. I couldn’t have asked for a better summer.