Skip to main content

Security conecpt

Introduction​

The manifest defines the focus of the component library. In terms of security, the following points can be highlighted:

  • The goal of the library is to provide consistent and accessible user interfaces for web-based projects.
  • The technical Scope of the library is limited thereby exclusively to the presentation layer.
  • In addition, the components do not contain any technical reference and are completely valid conceived.
  • Any technical context is given to a component from the outside into the component and is represented only.
  • There are beyond that no data transfer functionalities and storage.

Initial commit​

Before the source code was published, the following reviews were performed, among others:

  • Quality assurance: Basically, all reasonable quality-enhancing tools are used, which check the source code automatically and permanently (e.g. ESLint, TS-Prune, Tests, DepCheck, Prettier, Axe and many more).
  • Automatic code review: Using Teamscale, the entire source code was reviewed. Tools such as ESLint, Prettier and numerous test steps for compliance with the JavaScript/TypeScript programming guidelines of the ITZBund were used.
  • Manual code review: In addition, a code review was performed using a service provider to best implement the preparation for a public repository.
  • License review: For the selection of the open-source license, we follow the efforts of the European Commission with the European Union Public Licence v1.2.

Measures​

This section describes the measures taken to ensure safety on a permanent basis.

Code Review​

All Git repositories are configured so that changes can only be made via a pull request combined with a manual code review. manual code review. When a change is deployed via a pull request, all established review pipelines are set up review pipelines start automatically and provide feedback on the fulfillment of all quality benchmarks. If the change is is complete and all automated checks have been successful, a manual review by a core team member must take place. A core member may not merge his or her own change.

During the review, special attention must be paid to the following points:

  • the code must not contain any personal data or brand names
  • The contributor must have accepted the CLA
  • the scope of the code change must be reviewable (small-scale)

Contributor​

There are internal and external contributors (contributors). Internal contributors (core team) have extensive permissions in the Git repository and so directly on the source code and the resulting artifacts. External contributors, on the other hand, each have their Git repository, called forks or a copy. We (core team) have no influence on the forked Git repositories or copy.