DEV Community: Thibaut F. Batale

Streamlining Security Scans with secureCodeBox: My Google Summer of Code Journey

Thibaut F. Batale — Sun, 25 Aug 2024 19:04:20 +0000

Hey there, I’m Thibaut Batale, and I’m thrilled to share my experience as a Google Summer of Code contributor with OWASP secureCodeBox. Being selected to participate in this program was a unique opportunity, but what excited me the most was being chosen for the very first project I applied to. I wanted to spend this summer battling with Kubernetes, and I got exactly what I wished for—and more.

If you’re curious about my contributions during GSoC 2024, you can check out my Pull Requests on GitHub. You can also find more details about my project by visiting the Project link.

My Project: Introducing the secureCodeBox CLI

Imagine this scenario: You want to assess your security environment by testing for various vulnerabilities. With secureCodeBox, you can launch multiple security tests. However, traditionally, you would first need to create a YAML file defining the scan parameters and then use the kubectl command to apply that file. This process can be tedious and time-consuming, especially if you’re managing multiple scans.

This is where the scbctl CLI comes in. By providing a set of commands that interact directly with the secureCodeBox operator, the CLI tool simplifies and streamlines the process of managing security scans, making it more efficient and user-friendly.

During the summer, I focused on two main goals: implementing the new commands and adding unit tests to ensure their reliability.

Commands Technical Implementation

The commands implementation essential follows this workflow

1. Create Scan Command (`scbctl scan`)

The scbctl scan command was designed to simplify the initiation of new security scans. Instead of manually creating a YAML file and applying it with kubectl, users can now start a scan directly from their terminal. This command interacts with the secureCodeBox operator by creating a Scan custom resource (CR) in the specified namespace. The operator then processes this CR, triggering the appropriate scanner to run the specified tests.

Usage Example:

scbctl scan nmap -- scanme.nmap.org

This command creates a new Nmap scan targeting scanme.nmap.org.

Output:

🆕 Creating a new scan with name 'nmap' and parameters 'scanme.nmap.org'
🚀 Successfully created a new Scan 'nmap'

2. Observe Scan Command (`scbctl scan --follow`)

The --follow flag enhances the scbctl scan command by providing real-time feedback on the progress of a scan. Once a scan is initiated, users can observe its progress directly from their terminal. This feature interacts with the secureCodeBox operator by streaming logs from the Kubernetes Job and Pods associated with the scan, giving users visibility into the scan’s status and results as they happen.

Usage Example:

scbctl scan nmap --follow -- scanme.nmap.org

This command initiates a scan and follows its progress in real-time.

Output:

Found 1 job(s)
Job: scan-nmap-jzmtq, Labels: map[securecodebox.io/job-type:scanner]
scan-nmap-jzmtq📡 Streaming logs for job 'scan-nmap-jzmtq' and container 'nmap'
Starting Nmap 7.95 ( https://nmap.org ) at 2024-08-23 11:59 UTC
Nmap scan report for scanme.nmap.org (45.33.32.156)
Host is up (0.33s latency).
Other addresses for scanme.nmap.org (not scanned): 2600:3c01::f03c:91ff:fe18:bb2f
Not shown: 996 closed tcp ports (conn-refused)
PORT      STATE    SERVICE
22/tcp    open     ssh
80/tcp    filtered http
9929/tcp  open     nping-echo
31337/tcp open     Elite

Nmap done: 1 IP address (1 host up) scanned in 30.19 seconds

3. Trigger Scan Command (`scbctl trigger`)

The scbctl trigger command allows users to manually trigger a ScheduledScan resource. Scheduled scans are designed to run at predefined intervals, but there are times when an immediate execution is required. This command interacts with the secureCodeBox operator by invoking the ScheduledScan resource and creating a new Scan based on the schedule’s configuration.

Usage Example:

scbctl trigger nmap --namespace foobar

This command triggers the nmap scheduled scan immediately.

Output:

triggered new Scan for ScheduledScan 'nmap'

4. Cascade Visualization Command (`scbctl cascade`)

The scbctl cascade command provides a visualization of cascading scans—scans that are automatically triggered based on the results of a previous scan. This command interacts with the secureCodeBox operator by querying all Scan resources in a given namespace and identifying relationships based on the ParentScanAnnotation. It then generates a hierarchical tree that visually represents these cascading relationships.

Usage Example:

scbctl cascade

This command visualizes the cascading relationships between scans in the current namespace.

Output:

Scans
├── initial-nmap-scan
│   ├── follow-up-vulnerability-scan
│   │   └── detailed-sql-injection-scan
└── another-initial-scan
    └── another-follow-up-scan

Test Coverage Implementation

Testing was a crucial part of the development process, especially considering the complexity of the CLI commands and their interactions with the secureCodeBox (SCB) operator. Achieving an overall test coverage of 78% involved writing extensive unit tests that validated the behavior of each command and ensured they interacted correctly with the Kubernetes resources.

Mocking the Kubernetes Client

To simulate the Kubernetes environment and test the SCB commands without deploying them on an actual cluster, I used the fake.Client from the controller-runtime library. This allowed me to create a mock client that mimicked the behavior of the Kubernetes API, enabling thorough testing of the command interactions.

Here’s an example of a test case for the scbctl scan command:

testcases := []testcase{
    {
        name:          "Should create nmap scan with a single parameter",
        args:          []string{"scan", "nmap", "--", "scanme.nmap.org"},
        expectedError: nil,
        expectedScan: &expectedScan{
            name:       "nmap",
            scanType:   "nmap",
            namespace:  "default",
            parameters: []string{"scanme.nmap.org"},
        },
    },
    // Additional test cases...
}

In this test, I defined different scenarios to validate the command's behavior. Each test case included the expected arguments, any expected errors, and the expected state of the scan resource after execution.

Testing Command Behavior

The tests focused on validating that the CLI commands correctly created the necessary Kubernetes resources, such as Scan objects. For example, the scbctl scan command was tested to ensure it created a scan with the correct type, parameters, and namespace:

if tc.expectedScan != nil {
    scans := &v1.ScanList{}
    listErr := client.List(context.Background(), scans)
    assert.Nil(t, listErr, "failed to list scans")
    assert.Len(t, scans.Items, 1, "expected 1 scan to be created")

    scan := scans.Items[0]
    assert.Equal(t, tc.expectedScan.name, scan.Name)
    assert.Equal(t, tc.expectedScan.namespace, scan.Namespace)
    assert.Equal(t, tc.expectedScan.scanType, scan.Spec.ScanType)
    assert.Equal(t, tc.expectedScan.parameters, scan.Spec.Parameters)
}

This code snippet checks that the correct Scan object was created in the Kubernetes cluster, verifying that the CLI command worked as intended.

By running these tests and implementing these scenarios, I ensured that the scbctl tool behaved as expected under various conditions, contributing to the robustness of the secureCodeBox CLI tool.

Challenges

This summer wasn’t without its challenges. Balancing time became difficult when my school resumed, and I encountered several technical hurdles along the way. The most notable was implementing the --follow flag. Initially, we used the controller-runtime, but it lacked the necessary support for streaming logs. We considered switching to the go-client, but it introduced inconsistencies that could delay the project. After extensive discussions with my mentor Jannik Hollenbach, we decided to defer this feature for future implementation. This experience taught me the importance of thorough research and adaptability in problem-solving.

Overall Experience and Future Prospects

One of the most rewarding aspects of working on this project was the continuous learning curve. Whether diving into the complexities of the codebase or exploring the broader capabilities of secureCodeBox, there was always something new to discover. This constant evolution is what made the project so fascinating for me.

As the project reaches completion, maintaining and building upon these efforts is crucial. Looking ahead, I plan to focus on integrating monitoring features using the controller-runtime whenever its available, which will enhance the tool's ability to provide real-time feedback. Additionally, I aim to refine existing commands, particularly the cascade command, by adding flags to display the status of each scanner. This will provide users with more detailed insights into their scans. My commitment to improving and maintaining the project will ensure its continued success and relevance in the future.

Embarking on a Professional Growth Adventure: Insights from my LFX Mentorship Program at LitmusChaos

Thibaut F. Batale — Sun, 03 Dec 2023 17:08:30 +0000

Introduction

The Linux Foundation Mentorship Program offers a dynamic 12-week internship where participants engage in hands-on projects while receiving a stipend. When I first applied for the LFX mentorship program, I was a novice in the field and had no idea how this experience would impact my professional growth. Looking back now, I can confidently say that my journey within the LFX program has been transformative, teaching me the power of perseverance and learning.

One of the main reasons I was drawn to the LFX mentorship program was the fact that the project on which the mentee will be working was already set before the beginning of the application process. This allowed me to choose a project that aligned with my interests and skill set.

Early Challenges and Overcoming Them

My initial applications to the LFX program back in 2022 were unsuccessful, which served as a stark reminder of the competitive nature of this program. However, I refused to let the setbacks deter me and immersed myself in various open-source communities. This period was crucial for me as I honed my skills, expanded my understanding, and became more comfortable diving into any codebase quickly. This groundwork enabled me to craft a compelling proposal for the LFX program in Fall 2023, leading to my acceptance into my first-choice project – a perfect match for an area I was looking forward to improving.

The Mentorship Experience

My mentors, Sayan Mondal and Saranya Jena, were instrumental in my journey, providing guidance and support throughout the program. Our weekly meetings became a cornerstone of my learning process, where I shared progress, discussed challenges, and received tasks for the upcoming week. These tasks were primarily focused on adding unit tests for both the authentication server and unit, incorporating a new documentation for Chaoscenter API.

After a quick adaptation, I got my first task in the second week: to modify the code architecture to interface model for the environment service package and write test cases for it. Which I successfully accomplished. The satisfaction of having my first contributions merged was unparalleled.

Implementation

Test Cases for Auth server

1. Modifying the code architecture to interface model:

The first step in implementing test cases for the authentication server was to modify the code architecture to interface model. This was done to ensure that the code was modular and easy to test. This made it easier to test each piece of code individually and ensure that it was working as expected.

2. Creating a mock client of the services used by both GRPC and REST API:

The second step was to create a mock client of the services used by both GRPC and REST API. This was done to ensure that the test cases were isolated from the actual services. By creating a mock application service, I could simulate the behavior of the services without actually calling them.

3. Writing test cases to improve test coverage:

The final step was to write test cases to improve test toward improving the coverage. For each test, I created a new instance of the MockApplicationService and then passed a data test for different scenarios. One major issue I faced during this work was that the first scenario tested was directly impacting the new service instantiated from the mocked was affected by the first scenario that was run, so I was forced to use one scenario by test cases, but later on, I figured out that each scenario should have their one instance of the MockApplicationService, from there I was able created more a test cases and improved the coverage. Here is that particular PR

Tests Cases for Frontend Views Components

LitmusChaos uses a TestWrapper to encapsulate most of the dependencies that need to be mocked. For the first tests I wrote, I had to mock 2 main dependencies, the ReactqueryProvider and ApolloClient, but in order to ensure consistency and simplicity across the test cases, I implemented them into the TestWrapper and used the TestWrapper to wrap each component I wanted to test.

Incorporating API documentation for ChaosCenter API

For this, I decided to use an OPENAPI SPEC that will be used to automatically generate API documentation for each handler. For this work, I discovered a library called swaggo that I used to define annotations, from the description of the handler to defining responses. I created a doc file that lists all responses and errors from each endpoint, and to finish, I used go-swagger library to generate the API doc from the OPENAPI SPEC file generated by swaggo. Click here to learn more about the new API documentation of Litmus Chaoscenter

Achievements and Realizations

Throughout the program, I raised nine PRs, with eight successfully merged and one under review. My work not only increased the backend coverage from 0 to 25.48% and enhanced the frontend coverage from 0 to 14.56%. One of my essential suggestions was the implementation of a new workflow to track test coverage in the Chaoscenter auth server. My contributions laid a foundation for future enhancements by other contributors.

Moreover, I was able to register all 34 REST endpoints defining both Responses and the Return Error, which enables contributors to easily update the documentation page when a new endpoint is created just by modifying the annotations. This simplified the documentation process and made it more accessible for newcomers and existing contributors.

Challenges Faced

The journey was not without its challenges. One of the major issues I encountered during that time was writing positive test cases. I struggled to write positive tests for the GRPC and environment handler. I tried different approaches to mocking most of the services used by the handler, but after doing unsuccessful research on the internet, I asked for help from the community. I got referred to different resources on how to mock handlers using GIN. All these resources were super helpful and helped me write positive test cases and close this PR. That taught me that even though you have to figure out things on your own, it is OKAY to ask for help. It was my first time writing unit tests at this scale for a large project, but I learned, researched, and asked for help from my mentors.

What's Next?

After spending the whole fall working on this project, I plan to continue contributing to the testing strategy of LimusChaoscenter by helping new contributors who want to contribute to the project. I currently have one PR pending and a testing strategies documentation for Chaoscenter frontend to add. After that, I will maintain existing test cases and work on new ones.

Conclusion

The LFX mentorship program has been the most rewarding experience of my year. It has transformed me from a beginner in open-source to a confident contributor capable of making meaningful improvements. This experience enhanced my technical understanding of writing test cases, improved my Golang skills, and helped me gain insights into my code. I have learned that anything is achievable with the right amount of energy and time. Don't hesitate to submit your proposal for next quarter.

Thanks for reading.

By Magnim Thibaut F. Batale

Linkedin | Github
LFX'23 Mentee at Litmus

DEV Community: Thibaut F. Batale

Streamlining Security Scans with secureCodeBox: My Google Summer of Code Journey

My Project: Introducing the secureCodeBox CLI

Commands Technical Implementation

1. Create Scan Command (scbctl scan)

2. Observe Scan Command (scbctl scan --follow)

3. Trigger Scan Command (scbctl trigger)

4. Cascade Visualization Command (scbctl cascade)

Test Coverage Implementation

Mocking the Kubernetes Client

Testing Command Behavior

Challenges

Overall Experience and Future Prospects

Embarking on a Professional Growth Adventure: Insights from my LFX Mentorship Program at LitmusChaos

1. Create Scan Command (`scbctl scan`)

2. Observe Scan Command (`scbctl scan --follow`)

3. Trigger Scan Command (`scbctl trigger`)

4. Cascade Visualization Command (`scbctl cascade`)