OneDev exposure starts with project authority, not the login page
OneDev combines Git hosting, issue tracking, packages, and CI/CD. An internet-facing instance may look like a source-code server, while the authority behind it includes access tokens, job secrets, package write privileges, and build execution. Inventory should identify the deployment before an operator starts testing individual pages.
A count-only ZoomEye query on 2026-11-02 returned 271 assets for app="OneDev". The query used sub_type=all, page 1, and page size 1. The count describes matching product assets in ZoomEye's observation scope. It does not prove that all 271 are reachable, misconfigured, or vulnerable.
The ZoomEye query is an inventory lead. Pair the result with an ownership list, DNS records, cloud assets, and internal deployment records before treating any host as an organization's system.
Map the authority around the repository
OneDev's access tokens are managed from the user menu. The documentation notes that tokens can be created, edited, and deleted there. Project privileges still apply. A token may have code write or package write authority for a destination project, and a build job that pushes changes needs branch and tag protection to remain effective.
Job secrets are another identity boundary. OneDev documents job secrets so sensitive values are not embedded in a build specification. That is useful only if project readers cannot retrieve the secret through logs or an overly broad token. Review which jobs can use each secret and which branches can run those jobs. A token stored for a production deployment should not be available to a pull-request build from an untrusted contributor.
Package permissions use the same product account and permission system. Package read and write privileges can be granted through roles and project permissions. An exposed repository may therefore lead to an internal package registry. Inventory package namespaces and their publication identities as carefully as source repositories.
Build an exposure record
For each observed OneDev endpoint, record the hostname, IP address, TLS certificate, product version if disclosed, authentication method, organization, and first-seen time. Do not attempt to use default credentials or access tokens. Check whether the login page advertises a supported SSO flow and whether the deployment exposes administrative paths to the public internet.
Many organizations place OneDev behind a reverse proxy. Verify that the proxy does not expose an alternate origin, an old DNS record, or a service port that bypasses authentication. Compare public DNS and certificate names with the expected ingress. Check object storage or backup hosts associated with the repository, but do not assume they are part of the same deployment without ownership evidence.
OneDev itself can be fingerprinted with an app query, but a title or product match can also appear in documentation, mirrors, or unrelated search results. Treat the 271 count as a starting population. Confirm a positive match with a direct, authorized observation before adding it to a critical asset list.
Prioritize token and secret review
Start with accounts that can create projects, administer users, or manage authentication sources. Review access tokens by owner, creation date, permission, and last use where the product provides that information. Remove tokens that cannot be attributed to a job or integration. Rotate any token that was stored in a repository file, build log, container image, or public artifact.
Review job secret authorization by branch and project. Check whether a job can print environment values or call an external service with a token. A CI runner is a high-value execution environment, so its network access and mounted credentials deserve separate review from the web account.
Check anonymous permissions explicitly. A public release artifact can be intentional while source code and build logs remain private. OneDev documents this separation as a security tutorial. The configuration should express that intent rather than relying on a generic anonymous role.
Make monitoring repeatable
Run the ZoomEye query again on a schedule and compare new assets with the previous inventory. Alert on a new hostname, certificate, or app match associated with an owned domain. Preserve the query, scope, time, and count. A count change is an inventory signal, not evidence of compromise.
Inside the service, monitor token creation, permission changes, failed authentication, and unusual repository operations. Correlate those events with the configured identity provider. If the service supports webhooks or audit exports, send them to a system that retains evidence independently of the OneDev host.
An internet scan can show that OneDev is present. The security work is to determine which project authority sits behind that endpoint, which credentials can reach it, and whether the build system can be used to change code or packages outside the repository's reviewed path.
Top comments (0)