Background
openIMIS needed to evolve from MS IMIS to a generic standard product that can be fully customized and scaled to the needs of a growing number of implementing organisations. We had to realize a quick analysis of the source code considering its performance and persistence in terms of developments foreseen in the technical roadmap. The idea is to maintain theMS Visual Basic core while at the same time starting changes towards modularity and to explore options for a successively adding new / replacing old modules on the basis of open source technologies.
Result Summary
The results of the code review allowed to plan the following migration of the software package into the new modular architecture and to identify the most pressing vulnerabilities and pain points for quick fixes.
Methodology
The analysis was done by the members of the Developers Committee during the months of June and July in 2018 at a very high level with short examples from real code on the basis of the current master version in the github repository.
The review covers all aspects from the suggestions for a way forward from the technical roadmap, and is divided between evaluation of cross-cutting aspects and an evaluation per functional area.
The following elements were identified as out of scope for the current review
Link individual code files to functional areas
Interdependencies between modules
C# API
Detailed Results
| Panel | ||||||
|---|---|---|---|---|---|---|
| ||||||
The links in the lists below point to a document that is in a protected space and will only work for members of the review committee. You will not be able to access it. Kindly use the pdf copy of the report instead, which is attached to this page:
|
Cross Cutting Aspects
Scoring:
Implemented
Partially implemented
Not implemented
Cross Cutting Aspect | Score |
2 | |
2 | |
2 | |
1 | |
2 | |
3 | |
2 | |
2 | |
3 | |
1 | |
3 | |
2 | |
2 | |
2 | |
2 | |
2 | |
2 | |
2 | |
2 | |
2 | |
2 | |
2 | |
2 | |
3 | |
2 | |
n/a |
Functional Areas / Modules
Scoring:
Nothing to be done
Impact only on one application (e.g. user registration of web app)
Impact on multiple application(s) of the system (e.g. claim management on web app and web service)
Complete module needs to be redesigned
Functional Area | Bus. Proc. | Data Elem. | Loc. | Mod. |
4 | 4 | 3 | 3 | |
3 | 4 | 3 | 3 | |
4 | 4 | 3 | 3 | |
4 | 4 | 3 | 3 | |
4 | 4 | 3 | 3 | |
4 | 4 | 3 | 2 | |
4 | 4 | 3 | 2 |
Pain points
The following pain points have been collected during the code review.
Pain point | Possible mitigation |
Versioned code does not reflect all local changes | Ensure that every country runs on a checked in version, even if those are different branches |
Different country implementations maintained in branches means that code is diverging | Ensure that a basic customization mechanism is pushed to the master version (via configuration) and that country implementations are submitting pull-requests to master |
Implementation is bound to Microsoft SQL (See 2.4 Platform Independence) | Non-core modules: Ensure that most accesses to data layer are done via API calls rather than database. Core modules: Evaluate cost of porting data access layer to a database-independent Stored procedures: Redevelop stored procedures as a service with an API. |
Code is developed using outdated technology | Incrementally replace non-core modules with new technologies, while development teams are gaining experience with those technologies |
Deployment of a new OpenIMIS server instance is complex | Develop a windows-based Docker containerized version of OpenIMIS |
Key workflows are not customizable | The application should provide clear extension points so that workflows (for ex. Claimes or registration) can be customized. This customization could happen in Code or via an interface (more complexity) |
Security relevant issues (see issues in 2.1.1 Authentication, 2.1.2 Authorisation and 2.1.3 Data Transfer Encryption) | Fixes needed |
Audit logs are couple with business logic (see 2.1.4 Audit Logs) | Decouple audit logs from business logic. |
Data registered on mobile devices is not encrypted | Ensure that personal data in database on device is encrypted. |
Data privacy issues - see 2.1.5 Data Protection (according to GDPR) | Extensive data audit needed to suggest feasible solutions for encryption of personal data. |
Special calendar systems are not customizable | Support custom calendars throughout the application (Nepal support is only in front-end) |
Right-to-left not supported in the applications (web app and mobile apps) | Add support for right-to-left interface in both web app and mobile app. |
Code repository issues (partially resolved), see 2.5.1 Code Availability | Develop code repository guidelines (no build artefacts in repo, ensure separate modules are in separate repositories) |
No automated tests or continuous integration can impact software quality and development speed. | Develop tests for new modules, set up continuous integration service. |
Documentation is incomplete | Add documentation for mobile application |
Manual packaging process | Packaging process should be automatic (connected to continuous integration above) and should not require manual intervention |
Product names can only be in one language | Allow for product name and description in multiple languages |
Remediation
The most pressing security issues were further analysed in a follow up code review: 2018-11 Code Review .
The identified issues were the basis for the Modular Transformation of openIMIS the following year.
Report
| View file | ||
|---|---|---|
|
|