Jeremy Long

About Me

Jeremy Long

I am Jeremy Long, a passionate security professional and lifelong advocate for open collaboration and innovation. I currently serve as a Principal Security Engineer at ServiceNow, where I work on the DevSecOps team to secure our platform and software delivery pipelines using SAST, SCA, DAST, and creative workflow automation. My work focuses on integrating security seamlessly into the development process, empowering engineers to build safer, more resilient software.

My journey in security has always been driven by curiosity and a desire to solve hard problems. In 2012, I founded the OWASP Dependency-Check project, one of the very first Software Composition Analysis (SCA) tools, helping organizations around the world detect and remediate vulnerabilities in open-source software long before the term “SCA” was even coined. Today, Dependency-Check is used globally to protect the software supply chain and strengthen the open-source ecosystem. I have also spoken at both major security conferences as well as developer focused conferences.

I am deeply committed to mentoring others, fostering open collaboration, and giving back to the community. Security is a shared responsibility, and I believe that through education, open-source tooling, and global collaboration, we can empower developers and organizations everywhere to build a safer digital future.

Jeremy Long

What open source contributions, research or visible leadership work have you done? If few, what 3 specific outcomes will you deliver in your first 90 days on the board in OWASP and how will members verify the progress?

Over the past decade, I have been deeply involved in open-source security, both as a creator and as a collaborator. In 2012, I founded and continue to lead the OWASP Dependency-Check project, one of the first Software Composition Analysis (SCA) tools ever created. Dependency-Check has grown to become a globally adopted tool that helps organizations identify and remediate vulnerabilities in open-source components, strengthening the software supply chain worldwide.

Beyond Dependency-Check, I have contributed to several other OWASP projects, including the OWASP Java Encoder Project, multiple OWASP Cheat Sheets, Dependency-Track, and several CycloneDX plugins. My leadership extends to community building as well, having helped plan and run a previous OWASP AppSec DC conference and having served as a former leader of the OWASP Northern Virginia Chapter, where I focused on vendor-neutral, accessible education.

My commitment to the security community is also reflected in my research and public speaking. I have presented at multiple OWASP events and major industry conferences, including BlackHat USA 2023, where I spoke about defending against modern supply chain attacks like SolarWinds in my talk Reflections on Trust in the Software Supply Chain.

If elected, my first priority will be to address structural challenges faced by OWASP projects and to ensure our most active projects have the resources and visibility they need to thrive. My first 90 days will focus on three specific, measurable outcomes:

  1. Improve Support for OWASP Project Infrastructure
    Many projects, including my own, have faced challenges using essential services like Sonatype Central Publishing due to recent changes in their workflows.
    • Action: Review and document current pain points across projects and propose a set of clear recommendations for improving publishing, CI/CD workflows, and other shared infrastructure.
  2. Triage Stale or Abandoned Projects on GitHub
    The current OWASP GitHub organization has a large number of inactive or abandoned projects, making it difficult for members and newcomers to find active, supported tools.
    • Action: Work with the board, project leaders, and the community to propose changes that make it easier to identify active projects:
      • Create an automated project dashboard to track project activity.
      • Utilize GitHub Topics to improve project discoverability and indicate activity state.
      • Engage with inactive project leads to either revive or formally archive projects based on clear criteria.
  3. Continue and Improve Upon the Foundation for Sustainable Funding of Thriving Projects
    While OWASP thrives on volunteer contributions, maintaining a successful open-source project at scale requires consistent resources and financial support.
    • Action: Begin exploring partnerships and funding opportunities to help active, thriving projects sustain their growth and meet infrastructure needs.

By focusing on these three areas in my first 90 days, I aim to deliver meaningful improvements that make OWASP’s projects more effective, sustainable, and easier for members to engage with and trust.

What do you see as the top three challenges for OWASP to increase impact and visibility worldwide? Please provide actionable plan which you can spearhead and lead if need be for the goals you plan to achieve

Challenge 1:
OWASP has hundreds of projects, but many are inactive or lack clear status indicators. This creates confusion for new users and organizations trying to adopt OWASP tools, and it prevents active, thriving projects from getting the visibility they deserve.

Action Plan:

  • Implement consistent labeling within the OWASP GitHub organization to distinguish between active, experimental, and inactive projects.
  • Engage with project leaders of high-value tools to address historical infrastructure concerns and create a reliable, supported GitHub organization that they can trust.
  • Lead community discussions about potentially reorganizing OWASP’s GitHub presence to reduce clutter and improve discoverability.

Outcome:
OWASP’s most impactful projects will gain the visibility they deserve, and project leaders will have a clear path for hosting and growth. Members can track progress by:

  • Monitoring new labels and changes in the OWASP GitHub organization.

Challenge 2:

Challenge:
OWASP projects are the heart of the organization, and supporting them effectively is critical to our mission. While OWASP has an established Project Committee dedicated to representing project interests and providing guidance, there are still challenges in how the committee, the board, and project leaders work together.

Today, communication can be fragmented:

  • Project leaders may not always know how to raise issues or where to get help with infrastructure, governance, or policy challenges. Even on the Project Policy page, the Project Handbook is listed as TBD.
  • Feedback from active projects does not always flow consistently to the board, which can lead to delays in decision-making and missed opportunities to address problems early.
  • The Project Committee itself sometimes lacks the visibility and resources needed to fully support the diverse needs of OWASP’s global project ecosystem.

This misalignment can leave project leaders feeling disconnected from OWASP’s strategic direction and unsure how their feedback impacts board-level decisions.

Action Plan:

  • Work with the Project Committee to update and publish the Project Handbook, providing clear guidance on governance, communication channels, and support resources for project leaders.
  • Collaborate with the Project Committee to improve communication with OWASP project leaders, which could include regularly scheduled meetings to strengthen relationships and streamline communication channels.
  • Increase awareness of the Project Committee’s role among project leaders so they know how to engage and seek support.

Challenge 3:
OWASP already has a Project Policy that defines how projects should be started, maintained, and sunset (including activity thresholds, governance rules, and inactive project procedures). Yet in practice, many projects fall short:

  • Some projects don’t adhere strictly to activity requirements, governance guidelines, communication standards, or documentation expectations.
  • There is often no consistent enforcement or follow-through when projects become inactive or unresponsive.

This enforcement gap undermines trust, causes confusion about project status, and weakens the perceived reliability of OWASP’s ecosystem.

Action Plan:

  • Establish a Project Compliance Dashboard to track project activity and compliance with published guidelines.
  • Conduct an audit of all current OWASP projects to measure adherence to existing policy: governance structure, activity, discoverability, etc.
  • For non-compliant projects, facilitate a grace period and remediation plan, working with project leaders to bring them into compliance or mark them as inactive.
  • Recommend enhancements to the policy to incorporate regular reviews, automatic flags for inactivity, and cross-project consistency (e.g., standard governance templates).

Outcome:
Over time, OWASP’s project ecosystem will be more consistent, trustworthy, and easier to navigate. Members will see:

  • Public metrics via the compliance dashboard.
  • A reduction in projects in limbo (neither clearly active nor formally deprecated).

By addressing these three challenges — clarifying project visibility, strengthening communication, and enforcing existing policies — we can ensure OWASP continues to grow as a global force for good, empowering the next generation of security leaders and open-source innovators.

Several OWASP projects are stale and leads are unresponsive. If elected, what is your concrete, time bound plan to triage these projects, re-engage with inactive leads or relaunch based on clear criteria and timelines?


Stale or inactive projects create confusion for members, weaken OWASP’s brand, and make it harder for organizations to trust which tools and resources are current and supported. While OWASP already has strong Project Policies that outline activity requirements and governance expectations (policy.owasp.org), there is a gap between policy and practice. Many projects remain in limbo — neither fully active nor formally deprecated — because there is no consistent follow-through.

If elected, I will focus on closing this implementation gap with a clear, time-bound plan to triage projects, re-engage inactive leads, and ensure our ecosystem reflects only actively supported tools and materials.

First 90 Days: Audit and Engagement
  • Create a Project Compliance Dashboard to track activity and governance adherence.
  • Update the project policy to require clearly defined GitHub Topics on repositories to improve discoverability.
  • Based on the Project Compliance Dashboard, perform an audit of all current projects and categorize them based on activity:
    • Active and thriving
    • Active but at risk
    • Inactive
  • Reach out directly to project leaders flagged as inactive or at risk to:
    • Understand any challenges they’re facing
    • Offer support or resources to help them revitalize the project
    • Confirm whether they want to continue leading the project
Outcome

By systematically triaging projects, re-engaging inactive leaders, and creating clear visibility for members, we will:

  • Build trust in OWASP’s ecosystem.
  • Make it easier for contributors and organizations to focus on supported, high-quality tools.

This process will transform OWASP’s project portfolio into a clear, reliable, and sustainable foundation for the future of open-source application security.


OWASP can and should provide resources, tools, and educational programs that help individuals and organizations understand and meet their security, privacy, and data protection obligations — no matter what country or region they are in.

For me, it is not about whether a country is Arab, Asian, European, or anywhere else in the world — the mission remains the same: to empower developers, security practitioners, and organizations to build secure applications and systems. OWASP’s role is to provide clear, vendor-neutral resources and foster a global community that shares knowledge freely.



Watch Star