Open source software security is a big responsibility. Open
source is considered to be more secure than proprietary software, because more
widely the open software is available, more closely it is examined. And, the
more flaws that surface, the stronger a code becomes.
This would be true if the components, which make up the open
source code are constantly analyzed and if web application security services
are verified by the developers, before they are incorporated into their
work.
But, this is not always the case. Similar to automobile
assembly plants, which uses independently manufactured brake components and
airbags for building cars, software developers also assume that their supply
chain open source components are up to date, patched and reliable.
Regrettably, assumptions like these allow vulnerabilities
similar to those that were present in the Heartbleed bug.
There are a number of reasons why flaws exist in the open
source system: the components when used
for the first time might be old, or they might not have been appropriately
tested. But usually, an open source component that makes it into a broadly used
application is assumed to be safe, therefore, diminishing the demand for
testing.
Be Aware of What's in Your Software
The inventory of open source components is crucial, because
without that, IT managers will not be able to know if the system has
compromised components. One way of checking is through Application Health
Check, which provides free breakdown of each component and also alerts IT managers
of likely licensing and security problems.
When there is a defect in the open source, it's revealed,
but if you are not aware of the problems in your software, that revelation may
tip of enemies who can use it to exploit vulnerabilities. And hackers get
immense benefit by going after the components, which are extensively used, such
as Heartbleed attck/OpenSSL demonstrated.
Following are the ways for agencies to ensure that their
systems uses a secure software supply chain.
Usage of best ingredients: Agencies should ensure
that the components used are coming directly from a trusted archive. Search for
software that is compatible with CVE (Common Vulnerabilities and Exposures).
These are a set of standard identifiers known for exposures and security
vulnerabilities.
Make a list – IT managers should device and secure a
bill of materials, for the components that are used in a piece of software.
Scan the code – Automated code scanners, which are
compatible with SCAP (Security Content Automation Protocol), should be used.
Government-certified software should be used – Using
cryptography libraries that are FIPS-certified, for writing encryption
applications, eliminates the need of obtaining additional FIPS-certification.
Protect Your Business With mobile Security Services @ http://www.avyaan.com/blog/checklist-data-mobile-app-security/