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:
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
Settingstype 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 theworkToExportFilefunction.
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:
-
Added a new field in the GraphQL schema:
-
platform_export_timeoutunderSettings.
-
Modified the
workToExportFilefunction to read the timeout from settings instead of using the hardcoded 20 minutes.-
Implemented a fallback:
- If the setting is missing, the system still uses the default 20-minute timeout so older installations continue working normally.
Updated all places where
workToExportFileis 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:
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)