How do you Manage Security Risks in Open Source?

Open source is at the heart of almost every application. If you have ever developed a new application from scratch, the chance is very high that you’ve also built this on open source. In this post, I will outline security risks related to open source and give you a mitigation approach.

Reasons for open source

According to Gartner, 99% of mission-critical application portfolios within Global 2000 companies contains open source components. The complexity of our services is increasing. Users expect easy to use and responsive applications. At the same time, IT costs must be reduced. One approach to deal with this growing expectation and limited resources is building new applications on open source libraries which help developers to speed up their construction time.

Implementing critical functions such as encryptions or asynchronous processing can be both, time-consuming and challenging because there are many pitfalls involved. One being the in-depth knowledge of a particular topic which quickly leads to many hours of research. Another one being that the self-made component is erroneous. Therefore, many developers avoid reinventing the wheel and prefer open source components.


Your applications consist widely on open source libraries. I assume that you have a robust security test concept in place which also includes secure code scans according to industry standards. But, are you also aware of risks introduced by your open source components?

A static application security testing solution is unable to identify vulnerabilities without the actual source code. Typically, you don’t have the source of your open source libraries used in your business applications and your code scan solution will not point out any vulnerabilities within those.

Another often ignored risk are license terms of your open source components. While those libraries are free neglecting to comply with their requirements may result in business and technical risks.


First of all, you should be aware of all open source libraries are used across your applications and development projects. This open source inventory is essential because whenever a breach arises, you can quickly identify the affected application and apply a bugfix.

Secondly, regularly verify the known vulnerabilities in your open source libraries. Whenever you are using out-dated or vulnerable components, you should consider upgrading to the fixed version.

Finally, track what open source licenses you have used in your applications including their dependencies.

There are several secure code scan platforms out there which also provides an integrated solution for open source secure code analysis. Personally, I recommend using the Checkmarx Application Security Testing (CxSAST) solution.


Quick Start Guide for Security Tests

Software testers are sometimes unable to cope with the verification of security requirements because of their very technical nature. In this post, I will give you some guidance and orientation which you can use right away for your application security testing activities.

Step 1 – Static Application Security Tests

First of all, make sure that static application security testing or secure code review according to security standards such as OWASP top 10, SANS top 25 or PCI will be conducted. Bear in mind that vulnerabilities have to be eliminated from the root, which is the source code. You can do a manual code review or even better an automatic analysis using professional or freeware tools. Also, please verify the security risks related to open source libraries used by your application under test.

Step 2 – Dynamic Application Security Tests

Secondly, there are also security risks related to the surrounding application infrastructure. The application server, operating system, and additional runtime libraries can lead to serious hazards. Such so-called dynamic application security tests are always tool based, and baseline scans your runtime environment against known security issues. Typically, such application scans or penetration tests should be executed during system or user acceptance testing.

Step 3 – Business Security Tests

Lastly, your testing activities should also include so-called business security tests, which focus on sensitive areas such as authentication, authorization, and session management. Also, I recommend paying attention to login procedures and permission management of  applications under test. Conduct positive and negative tests for those critical areas mentioned above.

All things considered, a robust security testing approach incorporates early secure code reviews, dynamic and business security tests. Keep on doing the good work, and please share your own security testing experience and strategy with me.


Quick Start Guide for Secure Software Development

Software development does not always follow a well-structured process. Some companies tend to give developers more flexibility than others, which often results in critical vulnerabilities and high rework activities. Therefore, independent whether your projects follow agile or waterfall development principles, you shall apply some basic secure software development principles to avoid security loopholes.

The first one being, do not reinvent the wheel!

It might be that you have excellent ideas when it comes to encryption, authentication or authorization but the risk related to your self-made function in that area is obviously too high. Use only standardized encryption, authentication and authorization frameworks.

The second one being, that the input and output should be validated!

Nowadays, application-based attacks are one of the biggest security concerns. Due to their nature, those incidents are often difficult to detect because a firewall or intrusion detection system cannot distinguish between a real user and an application layer attack. Therefore, we should always validate all input independent from its origin. Also, we should also scan output prior sending it to the user.

The third one being, that prepared statements should be used!

Database access is a very attractive target of global cyber security attacks. Several big players have become a victory of database related so-called SQL injection attacks recently. If your developers exclusively use prepared statements for database access, your application will be robust against this critical attack.

The last one being that regular code scan should be scheduled!

Security issues must be eliminated from the root, the source code. Only secure code scans according to security standards such as OWASP top 10 or SANS top 25 will help you to identify and eliminate critical issues in your code during software development.

All things considered, the basic best practices mentioned above will push your software development projects towards security. Also, OWASP provides excellent background information for secure software development.

Why we need a Next Generation Technical Testing Platform

Our testing toolchain is quite impressive. Some are very specific, and others support a broad range of technologies and testing activities. However, when it comes to technical testing, more specifically, automated and performance testing there are still gaps. In this post, I will outline this cleft.

Typical technical testing activities

Independent whether you are following an iterative or agile development approach, you will implement automated regression tests, performance tests and security tests. You will start early in your development lifecycle and try to integrate also unit tests in your build process. Chances are very high that your test engineers will have four or more different testing tools in place.

The Problem

Our current technical-testing platforms are still limited concerning support for different testing activities. This gap leads to a high development and maintenance effort. We have many script redundancies, and in some cases, test implementation exceeds development effort.

The Solution

Based on my experience many successful organizations have automation, performance and security testing specialists in place. It would be a great productivity driver if those teams can use the same testing platform and testing scripts across their testing activities. This test asset sharing would lead to a rise in test coverage and test effort savings.

I hope that this post is a wake-up call for our testing solution providers. Start your engines and build a new technical testing platform which closes this gap.

Increase your Secure Software Development Maturity

Software development is often an unguided missile. Coding standards are seldom in place and developers decide what framework and libraries they will use for the implementation of their applications.

However, there are several excellent guidelines available which clearly describes the required measures to integrate security aspects in all software development steps. Personally speaking, I recommend the BSIMM guideline because it comes up with a maturity model and provides excellent benchmark metrics.

The table below contains a tailored, secure software development process according to BSIMM.


In this example the company decided to reach a higher maturity in implementation and test phases while analysis and design phases a lower maturity is sufficient.

More than 75 companies around the world are using BSIMM and those regularly provide their benchmark metrics. In the finance sector, the maturity level is between 1.8 and 2.8. Businesses who decide to switch to BSIMM could therefore easily compare their current maturity with their competitors.

Also, regulatory authorities such as MAS have already policies in place which specifies that some secure software development tasks such as code review and security testing have do be conducted pre-production.

Therefore, keep doing the good work and integrate security aspects in your software development chain.

Things you don’t want to hear about Development of Secure Software

Two of three security breaches account to vulnerable applications. Cyber criminals use vulnerable business applications to get access to confidential data without beeing detected.

I assume that some of us are already aware of successful attacks and how to search for vulnerable applications. I don’t want to tell you too much at this time, but if you are interested, you should have a look at the Google hacking database (GHDB), which allows a convenient search for specific security loopholes.

However, some wise companies have already applied measures to protect their valuable secrets. Some businesses are focusing more on infrastructure while others fundamentally transformed their development process towards security. Based on my experience is the latter the better approach while the former often does not provide sufficient protection for application layers based attacks such as SQL injection or cross-side scripting.

All things considered, don’t wait until you become a victim of a cyber-security attack. Integrate security aspects in your development process and eliminate security vulnerabilities from the root, the source code.

In my next blog post, I will give you a detailed overview of a streamlined, secure software development process.

Application Security Antipatterns

Cybercrime is on the rise and in 3 of 4 security breaches, hackers target vulnerable applications instead of the backend infrastructures. However, this trend is surprising because the risk reduction is quite simple.

The Attack
A common application layer security breach is not too complicated. Cyber criminals often use a standard computer and operating system, and with basic IT knowledge, they can conduct highly effective cyber thefts. All over the internet or locally available applications can become a victim of an application layer attack.

Since several years open web application security project (OWASP) provides statistics on most frequently used vulnerabilities. About 2 of 5 attacks are SQL injection or cross-side scripting (XSS).  The SQL injection vulnerability, for instance, allows cyber thefts eventually to bypass the login procedure by using ‘OR 1=1–‘ instead of a valid password.

The Risk Mitigation
Application layer firewalls are essential, but they will not provide sufficient protection against application tier attacks. Even hardening of your infrastructure does not reduce the risks related to becoming a victim of such an attack. The good news is; the risk mitigation is manageable.

Firstly you should educate your developers how to implement applications which are robust against top vulnerabilities.

Secondly, you should eliminate security issues from the root. Use Enterprise Security API to filter user input and never access your database without prepared statements.

Finally, you should regularly execute secure code reviews according to security standards.

Besides this, it’s better to use standard libraries for critical areas such as encryption instead of re-inventing the wheel.


NFR Testing should not be an afterthought

Our world is moving quickly and therefore, short time to market is more important than ever before. Everyone who is working in the software testing business is constantly challenged with reduction of testing time and shorter release sprints.

There are some who tend to cut quality assurance to the absolute minimum, and in some cases, the customers are assessing their products. I understand this trend to some extends but we need to keep in mind that our end user cannot test non-functional requirements.

While your end user community can conduct some functional tests, non-functional requirements must be verified in your test labor as early as possible in the lifecycle. Late detected performance or security faults would be expensive, result in frustrated user, or in worst cases, in critical outages or data loss.

However, make testing of non-functional requirements, namely, security and performance testing, part of your development pipeline. Also, NFR testing will reduce risks and gives you the opportunity proactively solve issues before they affect your user community.



Why you should combine Performance and Security Testing

Short turnaround cycles are more important than ever before.

New business requirements must be implemented within weeks to address upcoming trends and maximize return on investment quickly. While development time for such fast-line projects can hardly be shortened, test duration is typically reduced to the absolute minimum.

However, based on my experience you should choose a risk-based testing approach and tailor your testing strategy to risk reduction. Depending on the data being used by your application, functionality, security and performance need to be tested prior deployment on production.

Automated regression tests will help to reduce risk in the core business functionality. Performance engineers should analyze communication patterns and verify response time requirements. I recommend teaching your non-functional testing specialists to focus also on security concerns such as plain text passwords being sent in request parameters or forbidden external links being called from your application.

Keeping this in mind, performance testers will kill two birds with one stone.