DEV Community

Hitesh Sachdeva
Hitesh Sachdeva

Posted on

Release 0.4: Contributing a New Feature to OpenCTI - A Cyber Threat Intelligence Platform

Finding My Way to OpenCTI

When I started planning what I wanted to work on for Release 0.4, I knew I wanted something that would challenge me and align with my interests. I had already contributed a small UI fix to OpenCTI, but this time I wanted to understand its implementation in depth.

OpenCTI stands for Open Cyber Threat Intelligence. It is an open-source platform that helps organizations collect, store, and analyze cyber-threat information. It serves as a central hub where teams gather intelligence about attackers, malware, vulnerabilities, and more to protect their systems.

What drew me to this project was both the subject matter and the technology stack. OpenCTI uses JavaScript and GraphQL on the backend—technologies I'm familiar with and wanted to explore further.

Discovering the Issue

While browsing issues in the OpenCTI repository, I found Issue #13594:

https://github.com/OpenCTI-Platform/opencti/issues/13594

The issue described a limitation with the export feature. When users exported data (like reports, indicators, or other threat intelligence), the process had a hardcoded 20-minute timeout. For large datasets, this was not enough, causing exports to fail. And administrators couldn't change the timeout without editing the source code.

The request was simple: make the export timeout configurable through platform settings.

Why This Issue Appealed to Me

I chose this issue because:

  • It was a feature request, not just a small fix.
  • It solved a real problem for users handling large datasets.
  • It had the right level of difficulty.
  • I wanted to understand how OpenCTI handles platform settings, caching, and GraphQL schema changes.

Understanding the Codebase

Before making changes, I explored how OpenCTI manages settings.

  • The GraphQL schema defines a Settings type where platform configurations live.
  • Settings are stored in the database and accessed through a caching layer.
  • The export logic is implemented in work.js, inside the workToExportFile function.

This is where the 20-minute timeout was hardcoded. Once I found that, the path forward became clear.

My Implementation Approach

My goal was to follow existing patterns and keep everything backward compatible.

Steps I Took:

  1. Added a new field in the GraphQL schema:

    • platform_export_timeout under Settings.
  2. Modified the workToExportFile function to read the timeout from settings instead of using the hardcoded 20 minutes.

  3. Implemented a fallback:

    • If the setting is missing, the system still uses the default 20-minute timeout so older installations continue working normally.
  4. Updated all places where workToExportFile is called, since the function now needed the context and became asynchronous.

Challenges Along the Way

The main challenges were:

  • Understanding the caching system (getEntityFromCache).
  • Following OpenCTI's conventions for schema changes and code formatting.
  • Ensuring backward compatibility.
  • Testing different scenarios: no setting, custom timeout, and long-running exports.

Submitting the Pull Request

After testing, I submitted Pull Request #13608:

https://github.com/OpenCTI-Platform/opencti/pull/13608

I documented the changes, explained the implementation clearly, and linked the PR to the original issue. I also confirmed everything required in the PR template.

What I Learned

Working on this feature taught me:

  • How GraphQL schema changes flow through a large application.
  • How platform-wide settings and caching are managed.
  • The importance of backward compatibility in open-source projects.
  • How to navigate and contribute effectively to a mature codebase.

Looking Ahead

My pull request is currently awaiting review. I'm checking for feedback and ready to make improvements if needed. I plan to continue contributing to open source and exploring more complex issues.

Conclusion

This was a meaningful learning experience that helped me understand both the technical and collaborative sides of open-source development. I look forward to sharing updates on the progress of this contribution in my next blog post.

Top comments (0)