Scribd
Upload
10 views

Open-Source Software

⁸9

Uploaded by

pranshu1998
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
10 views

Open-Source Software

⁸9

Uploaded by

pranshu1998
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 4

Here's some information about open-source software and Flipside, a

company that uses open-source technology:

​ Open-source software
​ Open-source software is often free to use, and is developed by a community of
volunteers. Some advantages of open-source software include:
● Cost-effective: Open-source software is typically free to use.
● Community-driven: New features and standards are implemented quickly.
● Security: A large community monitors the development, making it more
secure.
​ Flipside
​ Flipside is a company that uses open-source technology to build web-based tools
that help organizations create social impact. Flipside believes that clients should
not be forced to depend on their support after a project is delivered. They use
open-source technologies to avoid vendor lock-in

The Myth of Open Source


Security

Open source software projects can be more secure than closed


source projects. However, the very things that can make open source
programs secure — the availability of the source code, and the fact
that large numbers of users are available to look for and fix security
holes — can also lull people into a false sense of security.

Many Eyeballs

The core open source phenomenon responsible for making code


secure is the “many eyeballs” effect. With lots of people scrutinizing a
program’s source code, bugs — and security problems — are more
likely to be found.

Why do programmers look at source code? Mostly for their own


benefit: they’ve found a piece of open source software useful, and
they want to improve or change it for their own specific needs.
Sometimes too, source code attracts scrutiny just to make sure it
meets certain needs, even when there’s no intention of modifying it.
Companies which require a high level of security, for example, might
do a code review as part of a security audit. This could be done for
any software product where the source is available, of course,
regardless of whether it’s open source or produced commercially.

Source code can also attract programmers’ eyeballs simply for


reasons of personal gain. Some people may explicitly wish to find
security problems in the code. Perhaps they want to build a name for
themselves in the security community. Maybe they’re motivated by
altruism or a belief that others should be aware of security holes.
Earlier this month, for example, two hackers broke into the open
source Apache Software Foundation Web site, posted a Microsoft
logo on it, and then published an explanation of how an improperly
configured FTP server allowed them access. Many others share
information about security vulnerabilities in less intrusive ways, such
as posting to discussions on the Bugtraq mailing list. And,
unfortunately, there will probably always be some people scrutinizing
source code because they want an attack that no one else has — in
which case, you’re not likely to gain much from their eyeballs.

People using open source programs are most likely to look at the
source code when they notice something they’d like to change.
Unfortunately, that doesn’t mean the program gets free security
audits by people good at such things. It gets eyeballs looking at the
parts of the code they want to change. Often, that’s only a small part
of the code. What’s more, programmers preoccupied with adding a
feature generally aren’t thinking much about security when they’re
looking at the code.

And, unfortunately, software developers sometimes have a tendency


to ignore security up front and try to bolt it on afterwards. Even
worse, most developers don’t necessarily know much about security.
Many programmers know a bit about buffer overflows, and are
probably aware of a handful of functions that should be avoided. But
many of them don’t understand buffer overflows enough to avoid
problems beyond the handful of dangerous calls they know. And
when it comes to flaws other than buffer overflows, the problem gets
worse. For example, it is common for developers to use cryptography,
but misapply it in ways that destroy the security of a system, and it is
also common for developers to add subtle information leaks to their
programs accidently.

Why Vulnerability Detection Is Hard

Vulnerability detection can be difficult for a number of reasons, including:

​ Snapshot effect
​ Vulnerability scans capture vulnerabilities that exist at the time of the scan, but
miss any new vulnerabilities that arise after the scan.
​ Known vulnerabilities
​ Vulnerability scanners focus on known vulnerabilities, and may not detect new or
unknown vulnerabilities, such as zero-day exploits.
​ Complex infrastructure
​ As organizations grow, their IT infrastructure becomes more complex, making it
harder to detect vulnerabilities.
​ Human input
​ Security experts may need to review scan results, complete remediation, and
follow up to ensure risks are mitigated.
​ Prioritization
​ Prioritizing remediation can be difficult, as it requires reaching consensus among
multiple people who may have different priorities.
​ Context
​ It can be difficult to determine intent from a connection to a port, even with
additional context. For example, a "known bad" connection may actually have a
good intent.
​
​ Two More Open-Source Fallacies

1>>The Microsoft Fallacy

Microsoft has been criticized for a number of issues, including:


​ Software security
​ Some critics have pointed out issues with the security of Microsoft's software,
including malware mishaps in the 2000s.
​ Monopolist practices
​ Microsoft has been accused of unlawful monopolistic practices, and the European
Union fined the company 899 million euros in 2004.
​ Locking in customers
​ Some critics have accused Microsoft of locking customers and vendors into their
products.
​ Standards
​ Some critics have accused Microsoft of not following or complying with existing
standards in its software.
​ Total cost of ownership
​ There is ongoing debate over the total cost of ownership of Microsoft Windows
compared to Linux.

2>> Java Fallacy

1. Java is slow (It is usually quite fast)


2. A single line of Java means anything in isolation (It doesn't e.g., because of what the
compiler might do)
3. A microbenchmark means what you think it does (Microbenchmarks are error-prone)
4. Algorithmic slowness is the most common cause of performance problems (Usually
algorithm choice isn't a huge problem)
5. Caching solves everything (Adding caching increases complexity, and doesn't fix the
underlying problem)
6. All apps need to be concerned about Stop-The-World (Profile before worrying about GC
overhead)
7. Hand-rolled Object Pooling is appropriate for a wide range of apps (Object pools are very
error-prone)
8. CMS is always a better choice of GC than Parallel Old (Make your choice of GC based on
profiling and testing)
9. Increasing the heap size will solve your memory problem (Heap size may not always help)

You might also like