Episódio 10: Construindo relacionamentos de segurança por meio da transparência
In this episode, Mike and Andreas discuss aligning with works councils, forging business relationships through transparency, and embedding security into value streams.

Building Security Relationships Through Transparency

Leia o Blog

Join Netskope at RSA Conference this year and be part of the real conversations on SASE and Zero Trust. Stop by our booth in South Hall, chat with an expert, register for our speaking sessions, and unwind by joining us at one of our events!

Saiba mais

Explore o lado de segurança de SASE, o futuro da rede e proteção na nuvem.

An Inside Look at How to Keep Open Source Software Dependencies Up-to-Date and Secure

Today, open source software provides the foundation for the vast majority of applications across all industries, and software development has slowly moved toward software assembling. Because of this change in the way we deliver the software, new attack surfaces have evolved and software security is facing new challenges inherent with dependency on open source software. A few examples of open source vulnerabilities which had a severe impact are Log4j and the SolarWinds Supply Chain Attack, among many others.

As per the Synopsys Open Source Security and Risk Analysis” (OSSRA) 2021 report, 84% of open source codebases have had at least one vulnerability with an average of 158 vulnerabilities per codebase.

Graph showing software supply chain attack trends — Software supply chain attacks trends

How the Netskope team addresses this

The Netskope Internal Security team utilizes Github Dependabot as one of the solutions to address the dependency problem. Dependabot keeps your dependencies up-to-date by informing you of any security vulnerabilities in your dependencies, and automatically opens pull requests to upgrade your dependencies to the next available secure version when a Dependabot alert is triggered, or to the latest version when a release is published.

Naturally, Dependabot aligns with the Netskope principle of embedding security in the developer workflow and being part of the developer experience by providing security-as-a-self-service.

Graph showing the effectiveness of Dependabot — Effectiveness of Dependabot

Pull request monitoring automation framework

At Netskope, my team took a further step to embed security in the developer experience and developed an automation framework, called sec-depend-aider, to monitor the pull requests created by Dependabot and feed it back to Jira into the right team’s bucket, where developers can triage and remediate it holistically along with other areas of work.

Additionally, the automation framework enables the Dependabot security alerts for all unarchived repos, if not enabled already.

We are happy to make the automation framework publicly available to align with another Netskope principle of giving back to the community, dutifully.

You can access our Open Source Automation Framework here. Here’s some additional detail around how this automation works, as well as best practices to consider when using sec-depend-aider:

Diagram showing automation architecture and workflow — Automation architecture and workflow

Key points

As depicted in the above architecture, the automation framework queries the GitHub REST and GraphQL API to fetch the information for pull request driven by the search query below

The automation relies on a custom configuration file to fetch the required information to generate tickets to Jira. We understand that this configuration will vary depending on your use-case, hence we are providing that part as a sample code and configuration. Feel free to change according to your environment.
Priority of the Jira ticket is driven by the Severity of Dependabot Alerts (parameter DEPENDABOT_JIRA_SEVERITY).
We are using Jenkins as a solution to run it periodically so that we can reutilize the existing communication integrations, though it will work just fine even with a cron job.
PoC Jira integration code demonstrates how an end-to-end process can be automated with custom configuration of varying needs.
The automation has a waiting period, governed by the “WAITING_PERIOD” parameter; only after that timeframe pull requests will be considered for further actions like Jira ticket creation.
In the end, the output is pretty-printed in table format, along with Jira tickets as actionable deliverables.

How you can use it

Create a repo to define the custom configuration (filename as custom-config.json in root directory of repo)
Update parameter DEPENDABOT_JIRA_SEVERITY to reflect your Jira severity definition
Set environment variables:
- GITHUB_ACCESS_TOKEN
- JIRA_SERVER
- JIRA_API_USERNAME
- JIRA_API_TOKEN

Future work

Integrate the automation with GitHub Action to either:
- Run from a centralized repository across the organization in a scheduled manner.
- Run from each repository with events like pull request creation or push to a branch.
We started the automation by defining a sink as Jira, but it can be easily reused for any technology, for example feeding the data into a SIEM for analytics.
We are already working on expanding the search query used in the automation to gather more datasets like GitHub Code and Secret Scanning Alerts.

For more information about this automation for sec-depend-aider, please reach out to [email protected] or open an issue from here.

Pramod Rana

Pramod Rana is leading the Netskope application security team with a primary focus on integrating security controls in the SDLC and security testing of Netskope product suite.

Mais informações