OpenHarmony Release History: Versions, Kernels, ArkTS and Security

OpenHarmony is an open source operating system framework for smart devices, incubated and operated by the OpenAtom Foundation. Its first release, 1.0, is dated 10 September 2020, and the project has since shipped the 3.x, 4.x, 5.x and 6.x lines, with 6.1 Release listed for 8 March 2026. It runs on three kernels (LiteOS-M, LiteOS-A and Linux), builds apps in ArkTS on the Stage model, signs every app package, and publishes a security bulletin every month.

This post walks through every release line with dates taken from OpenHarmony's own release notes, explains how the kernels and the mini, small and standard system types fit together, describes how apps are built, packaged and signed, sets out the security model in the project's own terms, and shows how to fetch a tagged release, build it and check it against the bulletins.

Key takeaways

• OpenHarmony is incubated and operated by the OpenAtom Foundation. Eclipse Oniro is a separate Eclipse Foundation project that builds on OpenHarmony and aims to be a compatible implementation.
• The release line runs from 1.0 (10 September 2020) through 1.1.0 LTS, 2.0 Canary, 3.0 LTS, 3.1, 3.2, 4.0, 4.1, 5.0.x, 5.1.0, 6.0 and 6.1. API levels moved from 8 (3.1 Release) to 20 (6.0 Release).
• Three kernels cover three system types: LiteOS-M for mini systems (MCUs, from 128 KiB of memory), LiteOS-A or Linux for small systems (from 1 MiB), and Linux for standard systems (from 128 MiB). The Linux kernel docs list 4.19 and 5.10, with 6.6 adapted for the RK3568 board.
• Apps are written in ArkTS, a TypeScript based language with stricter typing, on the Stage model introduced in API version 9. They ship as HAP packages and must be signed; code signing is on by default in the signing tool.
• The security model rests on an application sandbox, permissions tied to an Ability Privilege Level (normal, system_basic, system_core), a profile that binds the app to its certificate and permissions, and device security levels SL1 to SL5 that gate how data moves between devices.
• A Release branch is maintained for two years and an LTS branch for three and a half. During passive maintenance only vulnerabilities rated 7.0 or higher on CVSS are fixed. Bulletins are published monthly, and the September 2026 bulletin lists fixes for the 5.1.0, 6.0 and 6.1 Release branches.
• Downstream products ship their own builds. Your device is only as patched as the vendor's last merge from the branch it was built on.

What is OpenHarmony, and who governs it?

OpenHarmony's own overview describes it as "an open-source project incubated and operated by the OpenAtom Foundation", aiming at a distributed operating system framework for smart devices. The foundation hosts other open source projects too. Day to day work happens in Special Interest Groups (SIGs), and the Release SIG plans and publishes the branch roadmap.

The code now lives primarily on GitCode under gitcode.com/openharmony. Older documents point at Gitee, and a mirror is published on GitHub under github.com/openharmony, which is easier to fetch from scripts.

Where the code came from

The OpenHarmony 1.0 release notes, dated 10 September 2020, call it "the initial release for this product". The binary bundles shipped with that release were for three boards, the Hi3861 Wi-Fi IoT module and the Hi3518 and Hi3516 camera boards, and they were hosted at repo.huaweicloud.com/harmonyos/os/1.0/. The LiteOS-A kernel documentation says the OpenHarmony lightweight kernel "evolved from the kernel of Huawei LiteOS", a lightweight IoT operating system. Those two facts, taken from OpenHarmony's own documents, are the clearest public trace of the project's origin. We did not find an OpenAtom or OpenHarmony page in this research that states the donation date, so this post does not give one.

How OpenHarmony relates to HarmonyOS

OpenHarmony and HarmonyOS are separately named and separately versioned. OpenHarmony is the open source project governed by OpenAtom. The OpenHarmony documentation points developers to the HarmonyOS developer site for the DevEco Studio IDE and its automatic signing feature, so the tooling overlaps. This post does not describe HarmonyOS internals, because we could not fetch the HarmonyOS developer pages for this research and we only describe a product from its own documentation.

The practical point for security teams: a device described as "based on OpenHarmony" may contain code from the OpenHarmony tree, but its kernel version, patch level, signing roots and enabled features are decided by whoever built the image. Treat each one as its own distribution.

How Eclipse Oniro relates

Eclipse Oniro is an Eclipse Foundation project. Its website says it "was established through a collaboration between two global open source foundations: The Eclipse Foundation and The OpenAtom Foundation", and that it builds on OpenHarmony. The Eclipse project page for Oniro Core Platform describes the goal of building Oniro "as an OpenHarmony compatible implementation" and of using the Yocto Project tooling for hardware reach, and it adds React Native support on top for app developers. In short, Oniro is a downstream, vendor neutral distribution aimed at markets outside China, governed by a different foundation, with its own release process.

OpenHarmony release timeline: every version

The table below uses the dates printed in OpenHarmony's release notes index and in each version's own release note. API levels come from the SDK rows of each release note. Maintenance dates come from the project's version definitions page, which only lists branches up to 4.1; for later branches, the monthly security bulletins are the best public signal of what is still maintained.

Two cautions about the table. First, the 1.x line appears under two names: the release note calls the first LTS "1.1.0 LTS" dated 1 April 2021, while the maintenance table lists "1.0.1-Release" dated 30 March 2021 and the branch is named OpenHarmony_1.0.1_release. Both are official documents; they describe the same generation with different labels. Second, the release notes index dates 3.0.8 LTS to 3 March 2022, which falls before 3.0.7 LTS (5 December 2022). That looks like a typing error in the index, so check the individual release note if the exact date matters to you.

Label versions versus system versions

OpenHarmony uses two version numbers. Label versions are what the community releases, like OpenHarmony-v3.1.2-Release. System versions are four part numbers in the form major, minor, feature and build, which a device reports through the GetOsFullName() API. The project's mapping page shows that early labels did not update it: several 3.0.x LTS labels report OpenHarmony-3.0.0.0, and 3.1 Release reports OpenHarmony-2.2.0.0 on the standard system. Translate with the mapping page, and never assume the reported string tells you which fixes are present.

The 1.x and 2.x era: IoT first

OpenHarmony 1.0 was a mini and small system release: its three binary bundles were a Wi-Fi IoT module and two IP camera boards. The 1.1.0 LTS note calls itself "the first long-term support (LTS) version" and highlights a reconstructed LiteOS Cortex-M kernel for porting to third party chips. Porting is what turns a reference OS into many vendors' firmware, and each firmware image then needs its own patch stream.

2.0 Canary, dated 1 June 2021, is where the standard system appears. Its version table describes the kernel as "built based on the open-source Linux kernel LTS release" with CVE patches and OpenHarmony adaptation features merged on top, and it introduced a new application framework and JS UI framework. The release notes index now marks both the 1.x and 2.x series as end of life.

The 3.x era: LTS, Linux 5.10 and the arrival of ArkTS

3.0 LTS, released on 30 September 2021, is the first LTS branch that combined all three system types. Its release note lists Linux 5.10 support, including for the small system, alongside LiteOS. It added the ARK JS compiler toolchain and runtime, and in distributed networking it added permission verification when an app on one device accesses resources or capabilities on another. The maintenance table gives 3.0 LTS proactive maintenance until 30 September 2023 and full end of maintenance on 30 March 2025.

3.1 Release, on 30 March 2022, added RK3568 binaries for the standard system at API version 8, with local and distributed permission management and multi user support. Its last point release, 3.1.7, is dated 4 April 2023, and the branch reached end of maintenance on 30 March 2024.

3.2 Release, on 9 April 2023, is the version most developers would recognise. In its own words it "supports the development of large-scale applications and atomic services using the ArkTS programming language and stage model", and it records that the Stage model was introduced in API version 9. From a security angle, 3.2 added system pickers (PhotoPicker and FilePicker) so that apps get only the files a user selects, moved the key value database from a shared system sandbox into each app's own sandbox, added privacy settings for users, and tightened control over what pre-installed apps can do. 3.2 reached end of maintenance on 9 April 2025.

The 4.x era: formal ArkTS rules and Kits

4.0 Release arrived on 26 October 2023 with API version 10 and, according to its note, more than 4,000 new APIs. The language change is the one to remember: "The ArkTS syntax rules are officially defined and the ArkTS syntax check is added". From 4.0, the build tool flags code that does not follow ArkTS rules, which closes off many dynamic TypeScript patterns. Security additions included APIs to generate, sign, verify, encrypt and decrypt with SM2 keys, and a new system management interface permission. The maintenance table gives 4.0 an end of maintenance date of 26 October 2025.

4.1 Release, on 30 March 2024, is "the official release version for API level 11". It reorganised the developer surface into Kits. Three changes matter for security reviewers. The app-identifier in the signing certificate became the unique identity of an app, which supports "signature transfer" when a developer changes certificates. Cross device synchronisation is no longer allowed for data that has no security level. And the temp directory is now cleared when an app exits normally. 4.1 reached end of maintenance on 30 March 2026; its last point release, 4.1.4, is dated 30 May 2025.

The 5.x era: API 12 to 18

5.0.0 Release, on 29 September 2024, is the official release for API level 12. It added App Linking and Deep Link, which the note says improve "navigation security", further aligned C APIs with ArkTS so native code can do more, and refined picker based access: apps can get temporary access to files a user chooses, with optional persistence, and cannot read public directories such as Download without asking. Point releases 5.0.1, 5.0.2 and 5.0.3 followed through 21 March 2025, with 5.0.3 at API 15.

5.1.0 Release, on 30 April 2025, jumped to API version 18. Its note is dominated by ArkUI, media and window management APIs. The September 2026 security bulletin opens with a notice that 5.0.3 Release has stopped maintenance and that its vulnerabilities "will be no longer maintained", while 5.1.0 still appears in the affected version columns.

The 6.x era: API 20 and a newer web engine

6.0 Release is dated 6 September 2025 and ships SDK API version 20. Its note lists permission and privacy changes, such as letting an app query its own permission status, and a large upgrade to the ArkWeb engine: "upgrades the Chromium kernel from version 114 to 132". For security that is significant, because a web engine is often the largest open source component on a device and a common source of fixes in bulletins.

6.0.0.1 Release, on 23 December 2025, is a tag update. It says it "provides enhanced system security over OpenHarmony 6.0 Release by rectifying certain known vulnerabilities in open-source components such as Linux kernel", and its fixed issue table references both the Linux 5.10 and Linux 6.6 kernel repositories. 6.0.0.2 followed on 24 March 2026. 6.1 Release is listed in the index for 8 March 2026; at the time of writing the English release note file for 6.1 was not present in the mirror we fetched, so this post does not describe its features.

What kernels does OpenHarmony use?

OpenHarmony uses a multi kernel design and hides the differences behind a Kernel Abstraction Layer (KAL), so that system services and frameworks call one set of process, memory, file system and network interfaces regardless of the kernel underneath. The kernel overview gives this mapping:

LiteOS-M

LiteOS-M is the kernel for MCUs. The documentation describes it as small, low power and high performance, with a minimal function set, the KAL and optional components. It supports RISC-V and Arm Cortex-M3, M4, M7 and M33, and the source tree also carries a Cortex-M55 port. Isolation on these parts relies on a Memory Protection Unit (MPU), not virtual memory, so the security boundary between tasks is much weaker than on an application processor.

LiteOS-A

LiteOS-A is the kernel for small systems on application processors such as Arm Cortex-A. Compared with LiteOS-M it adds virtual memory, system calls, multi core support, lightweight inter process communication, discretionary access control (DAC) and multiple processes with isolated memory. It offers more than 1,200 POSIX APIs to ease porting. The documentation is explicit that LiteOS-A is not a microkernel: file systems and network protocols run in the kernel address space for speed. That design choice means a bug in those components runs with kernel privilege, which is worth knowing when you read bulletins that name kernel_liteos_a.

Linux

The standard system uses Linux, and the small system can too. The kernel docs say OpenHarmony uses Linux LTS versions as its base kernel, "Currently, it supports Linux-4.19 and Linux-5.10", and that the RK3568 board "has been adapted with Linux-6.6". The same page explains the reason for choosing LTS: a long maintenance window covers more of a product's life than a stable kernel's short one. OpenHarmony maintains its own kernel trees (for example kernel_linux_5.10 and kernel_linux_6.6), and the 6.0.0.1 note shows fixes landing in both.

Mini, small and standard systems compared

The overview says OpenHarmony runs on ARM, RISC-V and x86 architectures with RAM "ranging from hundreds of KiB to GiB". In practice, a single product family can include all three types: a hub on the standard system, a camera on the small system and sensors on the mini system, all expected to talk to each other.

How do OpenHarmony apps work?

Applications target the standard system. Four concepts cover most of what a reviewer needs.

ArkTS

The documentation introduces ArkTS as "a TypeScript-based programming language" that imposes "stricter limitations on the TypeScript's dynamically typed features" so code can be compiled ahead of time. It interoperates with JavaScript and TypeScript, so existing libraries can be reused. From 4.0, the rules are formal and checked at build time.

For security, ArkTS apps are not web apps in a wrapper: their behaviour is constrained by language rules and the permission system. Third party ArkTS and JavaScript libraries still come into the build, and each one is a dependency to track.

ArkUI

ArkUI is the declarative UI framework that ArkTS code uses. Pages are built from components and laid out by the framework, and the same page layout can be reused in widgets. Security components such as the SaveButton also live in ArkUI; they let a user grant one time access with a tap instead of a permission dialog.

The Stage model

The Stage model, introduced in API version 9, defines how an app's components run. Each HAP of the entry or feature type gets an AbilityStage instance when its code first loads into a process. Apps are made of UIAbility components, which have a UI and are each bound to a WindowStage holding a main window, and ExtensionAbility components for specific scenarios such as widgets, input methods and deferred work. Developers cannot derive directly from ExtensionAbility; they use the derived classes the system provides, which keeps background behaviour within system defined shapes.

HAP, HSP and HQF packages

A Harmony Ability Package (HAP) is "the basic unit for installing and running applications": code, resources, third party libraries and a configuration file. An app has one entry HAP and optionally one or more feature HAPs that can be installed on demand. A Harmony Shared Package (HSP) is a dynamic shared package, either within one app or shared across apps, and a Harmony Ability Package Quick Fix (HQF) is used to patch a HAP quickly on a device. The signing tool documentation lists .hap, .hsp and .hqf as the package types it can sign, along with binary debug tools.

How are OpenHarmony apps signed?

The signing documentation is direct: apps and debug tools "must be signed to ensure their integrity and trusted source. Only signed apps and debug tools can be installed, run, debugged, and used on devices." The tool is hapsigner, maintained in the developtools_hapsigner repository.

The certificate chain

OpenHarmony builds an X.509 trust system following RFC 5280. There are three tiers: a root CA certificate, an intermediate CA certificate, and entity certificates, which are either app signing certificates or profile signing certificates. The app signing certificate identifies the developer; the profile signing certificate signs the profile. hapsigner can generate ECC P-384 and P-256 keys and RSA 2048, 3072 and 4096 bit keys, create a certificate signing request, issue certificates, sign a profile and sign an app.

The profile

Every signed app carries a HarmonyAppProvision file, called the profile. It declares:

Because the APL and the access control list live in a signed profile, an app cannot simply declare its way into a higher privilege level. The profile has to be issued and signed by whoever controls the profile signing key for that device ecosystem.

Code signing

hapsigner's documentation says "The mandatory code signing mechanism provides validity check and integrity protection for apps in runtime" and that code signing "is enabled by default". It can be disabled. If you build images or sign apps for your own devices, make a decision about that switch on purpose, and write down who holds the signing keys.

The device side of trust is described in the device security guidelines: the OEM usually generates the key pair, presets the public key in the device, and keeps the private key on a local server that is not connected to the Internet. That is a key ceremony problem as much as a software one, and it is where most real world mistakes happen.

What is the OpenHarmony security model?

OpenHarmony describes security at three levels: app level controls on the standard system, device level controls that depend on hardware, and distributed controls between devices.

Application sandbox

All applications run in independent sandbox directories. The sandbox documentation calls it "an isolation mechanism used to prevent malicious data access through path traversal". Each app sees only its own application files plus the minimum system files it needs, which it can read but not write. To reach user files, an app goes through pickers or permissions.

Permissions and the Ability Privilege Level

Every app has a token ID that the Access Token Manager uses to track its identity, user, APL and granted permissions. Apps have one of three APLs, and permissions have matching levels:

A lower APL app cannot request a higher level permission by default. If a permission's "Enable via ACL" field is true, the profile's access control list can grant it across levels. Permissions also have an authorisation mode: system_grant permissions are granted at install time and cannot reach personal data; user_grant permissions must be declared and then approved by the user in a dialog at runtime; and from API version 21, manual_settings permissions must be enabled by the user in system settings. Apps must declare every permission they need, including those used by third party libraries, and should request the least they need.

Secure access through pickers and security components

The access control overview describes a third mechanism alongside the sandbox and permissions: system pickers and security components let an app temporarily access a resource the user selected, without holding the broader permission. A social app that needs a profile photo gets the one photo the user picked, not the Gallery. This model grew through 3.2 (PhotoPicker and FilePicker) and 5.0 (temporary and persisted file access).

Kernel level controls

Below the app layer, the device security guidelines describe process isolation through the MMU, DAC based on UID and GID, and the capability mechanism, and the project ships SELinux policy development guides for the standard system. Secure boot is described as a chain of signature checks starting from a root of trust in on chip ROM, with public key hashes stored in eFuse or one time programmable memory. A trusted execution environment, usually built on Arm TrustZone, can run iTrustee as the TEE OS, and the Universal KeyStore (HUKS) provides key and certificate management. The guidelines are clear that not every device needs a TEE; resource constrained devices with less sensitive services may skip it.

Device security levels and distributed trust

OpenHarmony's distributed features let several devices act as one "Super Device". The Device Security Level Management (DSLM) module exists because "Poor security capabilities of any device may threaten the security of the Super Device." Devices are classified into five levels:

The default level is SL1, and manufacturers can raise it for their devices. Services use the level to decide what data may move where; the docs give the example that distributed file storage does not allow sensitive data on devices below SL3. The DSLM APIs are native C interfaces for system components and are not open to apps.

Device to device trust is built with the device authentication platform (HiChain) and HUKS. The security guidelines describe peer to peer binding where the user enters or scans a PIN or QR code from the IoT device on the controller, followed by authentication and session key exchange. Since 4.1, data that has no security level cannot be synchronised across devices at all.

How are security patches and advisories published?

The openharmony/security repository holds the Security Issue Response Team charter, the vulnerability governance policy, the disclosure statement and the monthly bulletins.

Who handles vulnerabilities

The Security Issue Response Team is made up of people from the project's A category donors. Its jobs include monitoring external vulnerabilities, helping fix them, handling reports, code review and running the bug bounty programme. It has a leader and deputy elected for two year terms.

How vulnerabilities come in

The governance page lists the intake channels. A tool called cve-manager "automatically collects security vulnerabilities of upstream open-source software every day" and files issues through the project's CI bot account. Contributors file issues for upstream problems. LTS versions are "scanned for security vulnerabilities every month". Vulnerabilities in OpenHarmony's own code are reported by email to scy@openharmony.io, encrypted with the team's published public key, or as a private issue labelled Security. The team says it confirms and analyses reports "within three working days".

How they are scored and fixed

The project follows ISO/IEC 30111 and ISO/IEC 29147 and scores with CVSS 3.1. For LTS and Release branches, the policy is to fix all vulnerabilities during active maintenance and only those rated above 7.0 during passive maintenance, assigning a Security Advisory and a CVE ID. The lifecycle policy defines a Release branch as two years (one year proactive, one passive) and an LTS branch as three and a half years (two proactive, one and a half passive). In the passive phase, the community stops planning label versions and fixes only major or higher vulnerabilities and defects.

How they are disclosed

Disclosure is coordinated and usually monthly: the disclosure statement says "We usually disclose the vulnerabilities on the Tuesday of the first full week of each month." The bulletin index runs from 2021 to September 2026. Each bulletin is a table with the CVE ID, a one line description, impact, severity, CVSS 3.1 score, affected versions, affected repository and links to the fix commits for each maintained branch. You can subscribe to security@openharmony.io for bulletins. There is also a private distributors list that gives vetted downstream builders actionable information before public disclosure.

Reading a bulletin

The September 2026 bulletin, published 1 September 2026, opens with the end of maintenance notice for 5.0.3 Release. Its rows name component repositories such as the web view, peripheral drivers, the camera framework and kernel_liteos_a, list affected labels such as OpenHarmony-v6.0-Release, and link a separate fix for each branch. Read the affected version column against the exact label your product was built from, then confirm the fix commit is in your tree.

OpenHarmony versus the Android Open Source Project

This comparison stays at the level of governance and mechanisms. For per version Android details, see our Android release history.

The table does not rank the two. It shows that rules you know from one do not carry straight over to the other, which is the theme of the mistakes section below.

Step by step: fetch a tagged release, build it and check the bulletins

These steps follow OpenHarmony's release notes and quick start guides and need an Ubuntu build host with plenty of disk. Nothing here touches a device until you choose to flash one.

1. Install the repo tool

The release notes give this command for the project's repo build:

mkdir -p ~/bin
curl -s https://gitcode.com/oschina/repo/raw/fork_flow/repo-py3 > ~/bin/repo
chmod a+x ~/bin/repo
export PATH="$HOME/bin:$PATH"
pip3 install -i https://repo.huaweicloud.com/repository/pypi/simple requests

2. Choose a branch or a tag

A branch gives you everything merged so far, including later security fixes. A tag gives you exactly what was released. For a product, start from the branch that is still maintained, and record the tag you based each image on.

mkdir ~/oh-6.0 && cd ~/oh-6.0

# Exact release content
repo init -u https://gitcode.com/openharmony/manifest -b refs/tags/OpenHarmony-v6.0-Release --no-repo-verify

# Or the maintained branch with later fixes
# repo init -u https://gitcode.com/openharmony/manifest -b OpenHarmony-6.0-Release --no-repo-verify

repo sync -c
repo forall -c 'git lfs pull'

3. Record what you synced

Pin the exact commit of every repository so you can later prove which fixes are in your image.

repo manifest -r -o ~/oh-6.0-pinned.xml
grep -E 'kernel_linux|kernel_liteos|web_webview|chromium' ~/oh-6.0-pinned.xml | head

4. Fetch prebuilts and build

For the standard system on the RK3568 reference board, the quick start guide uses build.sh:

bash build/prebuilts_download.sh
./build.sh --product-name rk3568 --ccache
ls out/rk3568/packages/phone/images/

For a mini system such as the Hi3861 Wi-Fi module, install the hb build tool from the quick start guide, then pick the product interactively and build from scratch:

hb set
hb build -f

The build writes results and logs under out/<device_name>/, and the standard system images land in out/<device_name>/packages/phone/images/.

5. Read the bulletins for your branch

Fetch each month's bulletin from the security repository and filter for your label. The canonical copy is on GitCode; the GitHub mirror is easier to fetch from scripts.

for m in 2026-07 2026-08 2026-09; do
  curl -s -m 20 "https://raw.githubusercontent.com/openharmony/security/master/en/security-disclosure/2026/$m.md" \
    | grep -E 'OpenHarmony-v6.0-Release' \
    | cut -d'|' -f2,3,5,6,8
done

6. Confirm each fix is in your tree

Each bulletin row links a fix commit or merge request per branch. For a fix in a given repository, check your pinned commit includes it:

cd ~/oh-6.0/kernel/linux/linux-6.6     # path varies by repository
git fetch origin
git merge-base --is-ancestor <fix-commit> HEAD && echo "fix present" || echo "fix missing"

If a fix is missing, sync the maintained branch again or cherry pick the fix, rebuild, and record the new pinned manifest. Repeat monthly.

Common mistakes

Assuming Android app hardening rules carry over. OpenHarmony apps are ArkTS on the Stage model with a different package format, signing chain and privilege system. Android specific advice about manifest flags, exported components or signature schemes does not map one to one. Review OpenHarmony apps against its own permission, APL and profile rules.

Shipping a release tag and never merging the branch again. A tag is a snapshot. Fixes after the tag arrive on the branch and in later tag updates such as 6.0.0.1. If your build pins the tag and you never re-sync, every later bulletin applies to you.

Ignoring the passive maintenance phase. In passive maintenance only vulnerabilities rated 7.0 or higher are fixed. Medium and low issues stay open on that branch. Plan product timelines so devices move to a supported branch before the branch you used reaches end of maintenance.

Treating every downstream distribution as identical. A device "based on OpenHarmony", a commercial HarmonyOS device and an Eclipse Oniro build can differ in kernel version, enabled features, signing roots and patch level. Ask each vendor which label they built from and which bulletin fixes they have merged.

Trusting the reported version string alone. Some label versions do not update the system version a device reports. Verify fix commits instead.

Leaving debug profiles and keys in production. Ship release profiles, keep signing keys offline as the security guidelines recommend, and decide deliberately whether code signing stays on.

Over granting through ACLs. The profile's ACL lets an app hold permissions above its APL. Review every entry before you sign a release profile.

Forgetting the web engine and third party libraries. ArkWeb and other open source components appear often in bulletins, and app level libraries come into builds too. Inventory them like any other dependency.

Assuming the default device security level is high. The default is SL1. If distributed features depend on SL3 or above, the manufacturer has to raise and justify the level.

FAQ

Is OpenHarmony the same as HarmonyOS?

No. OpenHarmony is an open source project incubated and operated by the OpenAtom Foundation. HarmonyOS is a commercial product from one vendor. OpenHarmony documentation points developers to HarmonyOS tooling such as DevEco Studio, but the two are distributed and versioned separately.

What is the latest OpenHarmony version?

The release notes index lists 6.1 Release on 8 March 2026 and 6.0.0.2 Release on 24 March 2026. The September 2026 security bulletin lists fixes for 5.1.0, 6.0 and 6.1 Release branches, which shows those are the maintained lines as of that bulletin.

Does OpenHarmony use the Linux kernel?

The standard system uses Linux, and the small system can use Linux or LiteOS-A. The kernel documentation lists Linux 4.19 and 5.10, with Linux 6.6 adapted for the RK3568 board. Mini systems use LiteOS-M.

What programming language do OpenHarmony apps use?

ArkTS, a TypeScript based language with stricter typing that allows ahead of time compilation. The UI is built with ArkUI, and apps follow the Stage model introduced in API version 9. C and C++ are available through native APIs.

How long is an OpenHarmony release supported?

A Release branch gets two years (one proactive, one passive) and an LTS branch three and a half (two proactive, one and a half passive). In the passive phase only vulnerabilities rated 7.0 or higher are fixed.

How do I report a security vulnerability in OpenHarmony?

Email scy@openharmony.io, encrypted with the public key in the security repository, or open a private issue labelled Security in the affected repository. The response team says it confirms and analyses reports within three working days.

When are OpenHarmony security bulletins published?

Monthly. The disclosure statement says vulnerabilities are usually disclosed on the Tuesday of the first full week of each month. You can subscribe to the security@openharmony.io mailing list.

What are OpenHarmony device security levels?

DSLM classifies devices from SL1 (lowest) to SL5 (highest) based on their hardware and software security capabilities. Distributed services use the level to decide what data can move to a device, for example sensitive data is not stored on devices below SL3. The default is SL1.

How does Eclipse Oniro relate to OpenHarmony?

Oniro is an Eclipse Foundation project established in collaboration with the OpenAtom Foundation. It builds on OpenHarmony and aims to be an OpenHarmony compatible implementation, using Yocto Project tooling and adding frameworks such as React Native.

Why supply chain hygiene still matters here

OpenHarmony is maintained upstream and device images are patched by whoever builds them, so Safeguard's role here is indirect: it does not scan firmware, manage devices or patch kernels. It does help with the parts of an OpenHarmony product that are ordinary software supply chain: the ArkTS, JavaScript and native libraries in your apps, the build tools and containers on your build hosts, and the open source components you track against each bulletin.

Every rebuilt image and every app release pulls dependencies again, and the bulletins show that much of the fix volume lands in open source components such as the web engine and the kernel. The practices below close the gap between a fix being published and that fix running in what you ship.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo shows the local runner: you set it up on your own machine, approve it with its device code, then scan from the terminal. On an OpenHarmony project, the same flow scans an app repository or the container image you use as a build host, so you can see which open source packages and versions each one carries.

Click through it at your own pace, or open it full screen.

The second demo is a real Safeguard CLI session. You ask it to fix a vulnerable dependency, it reads the finding and the advisory, asks before any command that changes something, edits the manifest, runs the install and the tests with your approval, prints a summary and pushes nothing. The same pattern applies to bumping a JavaScript or native library in an app or tool repository that sits next to your OpenHarmony build.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. Once connected, you can ask in plain language which of your projects contain a given component version, and get answers from your own scan data.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard and follow the CLI documentation. If you run Safeguard on devices from the same vendor family, see Safeguard on Huawei devices.

Quick check

Sources

• OpenHarmony overview (OpenHarmony docs)
• OpenHarmony release notes index
• OpenHarmony 1.0 release notes
• OpenHarmony 1.1.0 LTS release notes
• OpenHarmony 2.0 Canary release notes
• OpenHarmony 3.0 LTS release notes
• OpenHarmony 3.1 Release notes
• OpenHarmony 3.2 Release notes
• OpenHarmony 4.0 Release notes
• OpenHarmony 4.1 Release notes
• OpenHarmony 5.0.0 Release notes
• OpenHarmony 5.1.0 Release notes
• OpenHarmony 6.0 Release notes
• OpenHarmony 6.0.0.1 Release notes
• OpenHarmony version definitions and maintenance schedule
• Mappings between label versions and system versions
• OpenHarmony version lifecycle management
• Kernel overview
• LiteOS-M overview
• LiteOS-A overview
• Linux kernel overview
• Introduction to ArkTS
• Stage model development overview
• HAP
• hapsigner overview
• HarmonyAppProvision configuration file
• Access control overview
• Application permission management overview
• Application sandbox
• Device security level management
• Device security guidelines
• Building source code with build.sh
• Obtaining source code and prebuilts
• Building for RK3568
• Security Issue Response Team charter
• OpenHarmony security vulnerability governance
• OpenHarmony security and disclosure statement
• OpenHarmony security bulletins index
• OpenHarmony security bulletin, September 2026
• OpenHarmony website
• Eclipse Oniro
• Eclipse Oniro project page
• Eclipse Oniro Core Platform
• Android app signing (Android Open Source Project)
• Android security bulletins (Android Open Source Project)

Last reviewed: 25 October 2026.