Intellectual Property & Open Source Policy

Last updated: 21 July 2026 · Applies to CYBORA (Vilnius, Lithuania) and CYBORA LLC (Delaware, USA)

This is a public summary of our internal policy. It's provided for transparency and general information, and isn't legal advice for your own situation.

CYBORA is an AI-native cybersecurity company operating in the EU (via CYBORA, Vilnius) and the US (via CYBORA LLC, Delaware). We build our own tools, produce security research and client deliverables, and rely heavily on open-source software to do it. This policy sets out:

• Who owns what, between CYBORA, our people, and our clients
• How we select and manage open-source components
• How we handle confidential and sensitive research
• How to reach us with questions

• Work created for CYBORA — by our team, in the course of their work — belongs to CYBORA. This is the standard rule under EU, Lithuanian, UK, and US law for employees, and we apply it consistently across both entities.
• Contractors and consultants sign a written IP assignment before starting any engagement. Under US law in particular, software isn't automatically "work made for hire" for a contractor the way it is for an employee — so we treat a signed assignment as a hard requirement, not paperwork.
• Pre-existing tools or code that someone brings into a project (rather than building for it) stay theirs unless they explicitly license it to us in writing.
• Client deliverables — reports, assessments, custom tooling built for a specific engagement — belong to the client once delivered and paid for, per the signed service agreement. CYBORA retains its own underlying methodology, templates, and general-purpose tooling (like our Risk Analysis platform), which we reuse across engagements.
• Client data and client systems always remain the client's. Any authorization CYBORA is given (e.g. to test a system) is limited to what's explicitly granted — never a license to reuse client data for other purposes.

Open source is core to how we build. We use it deliberately, and we track what we use.

License tiers

What this means in practice:

• Every product we ship maintains a Software Bill of Materials (SBOM) — an inventory of the open-source components inside it, their versions, and their licenses.
• Dependencies are scanned for known vulnerabilities as part of our build process, and critical issues are patched before release.
• Where a license requires attribution, we publish a consolidated notices file with the relevant product.
• Where we release our own tools or research as open source, we default to permissive licenses (Apache-2.0 or MIT) and review anything we publish to make sure it doesn't expose client data, credentials, or information that shouldn't be public.

This approach is also how we stay ahead of the EU Cyber Resilience Act (Regulation (EU) 2024/2847), which is introducing binding SBOM, vulnerability-handling, and incident-reporting obligations for software placed on the EU market between now and December 2027.

Security research is central to what we do, so we're direct about how we handle it:

• We only test systems we're explicitly authorized to test, with written scope and sign-off in place before work begins. Unauthorized access to computer systems is a criminal offense everywhere we operate — this isn't optional.
• Findings that could affect parties beyond a single client follow responsible/coordinated disclosure: the affected vendor is notified and given time to fix the issue before anything is published.
• Client-identifying details are never included in public research write-ups without explicit permission.
• We protect our own proprietary methods, tooling, and unpublished research as confidential business information, consistent with EU, Lithuanian, UK, and US trade secret law.

Where open-source components or our own tools process personal data, we handle that consistently with GDPR (EU/Lithuania) and UK GDPR / the Data Protection Act 2018 for UK-related data — including being careful about components that send data to third-party services outside the EU/UK.

• Licensing or IP questions: reach out via cybora.tech
• Vulnerability reports or security disclosures: we welcome responsible disclosure — please contact us before any public write-up so we can coordinate a fix.

This policy is reviewed periodically and updated as our tooling, licensing exposure, or applicable law changes. It's a summary for public reference; our internal policy contains additional operational detail that governs how our team and contractors work day to day.