The Security Group

The Security group is comprised of developers who participate in the design, implementation, and maintenance of Java Security components.

The current members of the Security Group are listed in the census.

Submitting Vulnerabilities

If you have any potential vulnerability to report, please see Oracle's Reporting Security Vulnerabilities page or the OpenJDK Vulnerabilities page.


The term "Security" has broad meanings and interpretations. It spans a wide range of areas, including cryptography, public key infrastructure, secure communication, authentication, and access control. The security component thus comprises a large set of APIs, tools, and implementations of commonly-used security algorithms and protocols.

The security area does not cover security features of the other primary component areas (language features and virtual machine implementations, core libraries, graphics subsystems, hotspot, serviceability, etc). For a more detailed treatment, please see the corresponding component pages.

The primary emphasis of these pages is to explore the core security components source bases, and hopefully, get developers up to speed quickly.

The Security Source Layout

The Java security components have been developed and expanded over the years, so the hierarchy may seem complicated simply due to the large number of source files and directories. But the files generally follow fairly straightforward patterns.

For general information about the OpenJDK repositories, and how to clone and build the JDK, see the OpenJDK Developer's Guide.

All of the security component source code is included in the OpenJDK project under the src subtree. As there are many different components, they are split into many subdirectories across several modules, generally based on functional area. In most cases, the main API and implementation-independent classes live in the java/* or javax/* hierarchy, and the implementation classes are in the sun/* hierarchy. Like any software projects, there are exceptions to this guidance.

Cryptographic Cautions

Anyone who has worked in cryptography knows the import/export of cryptographic code involves complicated legal issues. The JCE in OpenJDK has an open cryptographic interface, meaning it does not restrict which providers can be used. Compliance with United States export controls and with local law governing the import/export of products incorporating the JCE in the OpenJDK is the responsibility of the licensee.

Testing your changes

As a rule, unit tests for fixes and new functionality are pretty much mandatory. However, before submitting changes, you should run the relevant regression tests to make sure that the existing tests continue to pass. For the security component, at a minimum you should run:

You can run the security tests with make test:

make test TEST="jdk_security jdk_security_infra"

To run a single test, specify the pathname of the test, ex:

make test TEST="test/jdk/java/security/Provider/"

It is also a good idea to run all tests in tier1 and tier2 for more assurance that your change won't break other parts of the JDK:

make test TEST="tier1 tier2"

See the Testing the JDK section of the OpenJDK Developer's Guide for more details on how to write and run tests. If your changes break something, it will be a lot more work to diagnose, and then fix or back out. Do as much testing as possible.


Issues are tracked in the JDK Bug System. Security bugs are tracked in the security-libs component. There are several subcomponents depending on what area the issue affects:,,, javax.crypto, javax.crypto:pkcs11, org.ietf.jgss, org.ietf.jgss:krb5, javax.xml.crypto, javax.smartcardio, and