Our security focused software development services specializing in helping company leaders like yourself. We promise to get your software development two times quicker and security focused so you have more time to do new releases, and other things you need to do. Interested in getting your company brand secured by an experienced team that knows the way? Customers love how easy to start with Java OSGi development framework. The big benefit is that it helps business leaders, managers to control more about software design, security related risks. They can identify immediately what risks have about the product, which features are risky, and much more. This helps them change their development process to match the security standards, ultimately increasing company brand recognition and generating more sales.

1. AN EFFICIENT
SECURE SOFTWARE DEVELOPMENT
FRAMEWORK

2. CONTENT
THE TOOLSET:
OSGI & THE EVERIT FRAMEWORK
Cleaner the code - healthier the software
Decreasing complexity - fail proof operation
Streamlined development - bulletproof application
THE METHODOLOGY
Design
Analysis, precautions
Processes under control
Shorter iteration, fewer bugfixes
Authenticity and undeniability
Awareness, vigilance
Corresponding partnership
1

3. Before we start to introduce our solution, let’s clarify what we
mean when we are talking about secure software develop-
ment.
In our opinion, this means to keep our eyes on certain se-
curity requirements during the whole development project.,
which also means that we actually do have some security
requirements.
On the other hand, we have to consider these requirements
also when we choose our toolset, and later during the utili-
zation of these tools.
In short, it is all about the proper tool used in a suitable
way.
SECURE SOFTWARE DEVELOPMENT
THE EVERIT WAY
2

4. In our case the chosen tool is the EverIT framework, built on
the Java OSGi platform.
Even the Java language, or the OSGi platform itself could be
the subject of a security analysis, but this is not what we are
aiming for here.
We would like to focus on our own experiences, which were
collected during our security sensitive projects. Namely the
OSGi platform itself can not be called secure, but it provides
many possibilities, through which an OSGi based product
can be made secure.
The complete list of the advantages of the OSGi platform
will not be listed here either, as it can be reached under the
OSGi Alliance site.
The following parts of this document will guide you through
the essence of our experiences.
THE TOOLSET
OSGI & THE EVERIT FRAMEWORK
3

5. In recent years we have had a few projects, where the
initial Java EE platform was changed to OSGi during the
implementation phase, and we had very impressive re-
sults each time.
In these projects our lead developers experienced that
the modular architecture helped us produce cleaner
code, thanks to the conventions of OSGi. So during the
process of code reviews it was much easier to notice the
details (placed by accident or even on purpose) which
could cause vulnerability.
This could be complemented by a proper checkstyle
policy and a well configured CI (continuous integration)
system, but this is rather to do with the cut back on the
overload which typically affects our lead developers.
So altogether it is beneficial, because with these tools a
better code coverage is available during the reviews and
even the review can be deeper and more effective. Not to
mention that the system administrators get a more easi-
ly maintainable application, so the filtration of a malware
activity or a noxious code-snippet could be more efficient.
CLEANER THE CODE
HEALTHIER THE SOFTWARE
4

6. According to our benchmark results, using the OSGi
technology and our self-developed framework, we could
reach one, and in some cases even two magnitude better
response time compared to a traditional Java EE applica-
tion. So the system’s load bearing capacity can be higher,
and that is how they can be considered more protected
against dos and ddos attacks.
Of course there is no system (not even based on OSGi)
which can not be flooded, but with a modular, OSGi ap-
plication this threshold is higher, assuming the same
amount of resource on the attacker side.
On one hand, we could force the attackers to make some
extra effort, which will make the target (our software or
system) less tempting. On the other hand, we can gain
some time for other defense mechanisms to start before
the attackers reach their goal.
Similarly, but on the failover side, a lightweight OSGi ap-
plication with quicker booting process brings some extra
confidence for the administrators compared to a mono-
lithic, complex system. This factor could be mission criti-
cal in case of a service with high availability and SLA.
Furthermore, according to Amdahl’s law, the speedup of
a given problem’s solution by parallelization is only pos-
sible up to a certain point, so the benefits of OSGi will not
disappear even if the availability of resources is relatively
high.
So in this case we can state that simplicity means
security.
DECREASING COMPLEXITY
FAIL-PROOF OPERATION
5

7. Many years of continuous research and endeavour to-
ward perfection led us so far, that we are not willing to
compromise in certain cases. One such example is tech-
nologies we use to ease and support development.
Our experience shows that in this case less is often more.
The more support or predefined comfort service you get
from a tool or technology, the higher is the risk that you
will find yourself in a tight dependency, and you could
lose your competitive advantage very quickly if a critical
bug emerges (and it will with a good chance).
Probably every developer knows the helpless feeling,
when a bug turns up in a third party code, out of his au-
thority, and the application gets into a vulnerable state
(and stays for a while) without anything we can do to find
a solution.
The less dependency from various technologies we have,
the less exposed state we are in. This is what we believe
in, and we try to use our self-developed framework in ev-
ery possible case.
STREAMLINED DEVELOPMENT
BULLETPROOF APPLICATION
6

8. If we can not avoid taking an external dependency into
our technology stack, it has to be a subject of an inspec-
tion, just as accurate as if it were our own development. In
this area we require the very same QA rules we do in case
of internal development.
As a result, many modules have been created under
our framework, which are functionally equivalent to oth-
er (well-known) competitors on the market, but to keep
things under control can be priceless in certain cases.
That (and of course the availability of customization) is
why it is worth to make our own implementation of these
elements.
This is how we created our own OSGi based authorization
and authentication (and many others) components in or-
der to leave the Spring Framework.
However the framework does not give a 100% coverage
to all technologies and not every technology was written
in an OSGi approach, so sometimes they can not be used
in an OSGi environment. Therefore, when we receive a
request we can not fulfill with our existing solutions, we
have to count with some additional effort, financially and
in time also.
But at the end these efforts will result in better quality,
and later it can help save some bugfix and some sleep-
less nights for the team.
STREAMLINED DEVELOPMENT
BULLETPROOF APPLICATION
7

9. The tools described in the previous chapter are worth
nothing if we do not use them in a suitable way, or if we
make mistakes during the system design.
That is why the methodology is so important from the se-
curity point of view, maybe even more important than the
tools themselves.
Realizing this relevance we have introduced some proce-
dures which help us produce a higher quality and more
secure software.
In some cases these are expanded to the whole organisa-
tion, otherwise they are built in the development process.
The origin of these procedures are the Common Criteria
(CC) and the Agile/Scrum methodology, which two prin-
ciples we managed to merge into our own hybrid project
management technique in order to create custom soft-
ware solutions with particular security regulations.
The following chapters present a number of practical fea-
tures of this technique.
THE METHODOLOGY
8

10. The base of every development is a precise design,
supported by a consistent technique, which also in-
cludes a suitable toolset.
At the design stage our choice was UML and Enterprise
Architect, and we try to exploit the advantages of this
versatile tool.
However, we pay meticulous attention not to immerse
in the design in such depth, which would obstruct the
lean approach of the product development and the ag-
ile organization of work.
DESIGN
9

11. When developing web-based applications, we bring
the OWASP list into sharp focus in the testing phase.
However, it is also necessary to examine the possible
vulnerability factors and hypothetical attack forms al-
ready in the design phase.
This allows us to build in the requisite controls and de-
velop an application which will not fail later on the pen-
etration tests.
ANALYSIS & PRECAUTIONS
10

12. From the design cycle, through the implementation,
testing and release sub-processes, we handle the mat-
ter of traceability with top priority. We believe we found
the perfect toolset to support this pursuit: Git for version
control, and Jira for project and process management.
Another key component of secure services or the se-
cure software development is the existence of the con-
venient staging process and the necessary staging en-
vironment.
The permission and access control management, in-
stalled already at the beginning of a project, is also part
of the practice. We managed to create without compro-
mise nearly perfect conditions for this purpose, with the
help of our self-operated server infrastructure.
11
PROCESSES
UNDER CONTROL

13. We noticed at EverIT (and also at some partners where
we work with the same methods) that Agile (e.g. Scrum)
and Lean concepts help us bring down the product de-
velopment costs and allows us to access the targeted
market quicker.
Beside this very important (but from a security point of
view not so relevant) aspect, we had another exciting
realization: Thanks to the more frequent version up-
grades, the smaller release packages contain overall
fewer bugs.
And if a bug does turn up, the identification and cor-
rection can be more effective and faster. This is the trait
which is extremely relevant in the field of security.
12
SHORTER ITERATION
FEWER BUGFIXES

14. Being the main technological partner of Netlock Ltd.
the leading, qualified Certificate Authority in Hungary,
we are especially proud of our PKI-related develop-
ment know-how.
In our custom development projects we provide differ-
ent PKI solutions (the use of certificates, timestamps,
etc.), which can grant authenticity and undeniability in
accordance with customer needs.
We have great expertise in building in such enhanced
security controls into various functions.
13
AUTHENTICITY &
UNDENIABILITY

15. The most typical point of failure is the human factor,
so awareness, consciousness and preparedness of our
colleagues is key.
To keep this factor always in focus, the guarantee is our
ISO27001 information security management system
(ISMS), whose practical procedures include recurring
security trainings, professional studies, and continuous
self-inspection proceedings.
14
AWARENESS
VIGILANCE

16. We work in close cooperation with a software security
facility accredited by the OCSI, under the Italian Com-
mon Criteria (CC) Scheme.
The laboratory’s main profile is security support for
software development and software evaluations up to
EAL4+ level.
During this partnership, we have managed to clarify a
number of considerations and directives based on the
CC.
We strive to start all of our projects to be fit for the
EAL4+ definition, and bring “methodically designed,
tested, and reviewed” softwares into existence.
15
CORRESPONDING
PARTNERSHIP

17. CONTACT US FOR A CONSULTATION:
WEB: dosell.io
EMAIL: tibor.zahorecz@dosell.io
MOBILE: +36 30 836 4099
LET US HELP YOU
WITH SECURE SOFTWARE DEVELOPMENT!