The complete guide to developer first application security By Github.Com

The complete guide to developer first
application security By Github.Com install
download
https://ebookmeta.com/product/the-complete-guide-to-developer-
first-application-security-by-github-com/
Download more ebook from https://ebookmeta.com

We believe these products will be a great fit for you. Click
the link to download now, or visit ebookmeta.com
to discover even more!
Certified Kubernetes Application Developer CKAD Study
Guide 1st Edition Benjamin Muschko
https://ebookmeta.com/product/certified-kubernetes-application-
developer-ckad-study-guide-1st-edition-benjamin-muschko/
Java Platform Standard Edition Security Developer s
Guide Oracle
https://ebookmeta.com/product/java-platform-standard-edition-
security-developer-s-guide-oracle/
The Prime Guide For Next Gen Developer First Edition
Ankur Tyagi
https://ebookmeta.com/product/the-prime-guide-for-next-gen-
developer-first-edition-ankur-tyagi/
Internationalization Speed in the Context of
Diversified MNEs A Literature Review on
Internationalization Speed and an Empirical Study on
the Internationalization of New Business Units 1st
Edition Martin Hammes
https://ebookmeta.com/product/internationalization-speed-in-the-
context-of-diversified-mnes-a-literature-review-on-
internationalization-speed-and-an-empirical-study-on-the-

Warhammer 40 000 Codex Orks 9th Edition Games Workshop
Ltd
https://ebookmeta.com/product/warhammer-40-000-codex-orks-9th-
edition-games-workshop-ltd/
Master Mass Communication A Fresh Introduction to Mass
Comm 1st Edition Richard J Ganahl
https://ebookmeta.com/product/master-mass-communication-a-fresh-
introduction-to-mass-comm-1st-edition-richard-j-ganahl/
Genesis European Studies in Theology Philosophy and
History of Religions Adamczewski
https://ebookmeta.com/product/genesis-european-studies-in-
theology-philosophy-and-history-of-religions-adamczewski/
Clinical Cases in Endocrinology 1st Edition Pramila
Kalra Editor
https://ebookmeta.com/product/clinical-cases-in-
endocrinology-1st-edition-pramila-kalra-editor/
Attracting Beneficial Bugs to Your Garden A Natural
Approach to Pest Control 2nd Edition Jessica Walliser
https://ebookmeta.com/product/attracting-beneficial-bugs-to-your-
garden-a-natural-approach-to-pest-control-2nd-edition-jessica-
walliser/

Good and Evil in Shakespeare s King Lear and Macbeth
1st Edition Alina Degünther
https://ebookmeta.com/product/good-and-evil-in-shakespeare-s-
king-lear-and-macbeth-1st-edition-alina-degunther/

T H E C O M P L E T E G U I D E T O D E V E L O P E R - F I R S T A P P L I C AT I O N S E C U R I T Y 1
The complete guide
to developer-first
application security
W R I T T E N B Y G I T H U B W I T H ❤

Contents
10
16
33
24
Part one: State of application
security today
Part two: Traditional vs.
end-to-end security
Conclusion
Part three: Developer-
first application security
with GitHub
3
5
Introduction
Executive summary

Introduction

As a result of globalization and digital transformation,
business now runs on ones and zeros. No matter the
industry, high-performing organizations all compete for the
same advantage: Transforming the customer experience
into a digital-first medium that stands out.
Since applications fuel these digital experiences, developing
applications needed to deliver business processes has
become a core competency for organizations of all sizes; every
company is now a technology company. At the same time,
enterprise applications’ increasing use and importance create
a prime target for malicious actors—resulting in devastating
data breaches. While it can be difficult to pinpoint the initial
attack vector for breaches, in retrospect, many of the biggest
recent breaches are known to have leveraged vulnerabilities at
the application layer.1
Given how critical applications are to many businesses—
both in terms of the functions they provide and the data they
process—why do we keep experiencing application security
breaches? Despite an emphasis on application development
and improved application security, application vulnerabilities
continue to grow linearly with lines of code. How can we break
this relationship in order to deliver more secure applications?
In this ebook, we’ll take a look at the current state of
application security and recommend sustainable solutions.
We’ll also share GitHub’s responsibility in securing the world’s
software, and how GitHub helps organizations deliver more
secure applications and empower innovation.
I N T R O D U C T I O N
--------
1: 2020 Open Source Security and Risk Analysis Report, Synopsys

Executive
summary

Part one: The current state
of application security
Application security leverages a system of tools, processes,
and best practices to manage application-related business risk.
Depending on risk appetite and the criticality of applications, as well
as security program maturity, application security can range from
simple risk awareness to a well-established pipeline that quickly
identifies and remediates vulnerabilities, ideally pre-production.
Modern software is built on open source, but as the adoption of
open source components increases, so can security risks for both
developers and security teams.
For the average organization today, application security consists of
a small set of testing tools integrated with the software development
cycle. Common current concepts include static application security
testing (SAST), dynamic application security testing (DAST),
passive and active integrated application security testing (IAST),
runtime application security protection (RASP), fuzzing, software
composition analysis (SCA), penetration testing, and bug bounties.
Depending on an organization’s maturity level, tooling, and
capabilities, application security is either treated as the final
gate before deploying an application, or as a series of tests
integrated with the development cycle.
E X E C U T I V E S U M M A R Y

Part two: Traditional vs.
end-to-end security
Traditional approach: Security as a gate
Having security as a gate prior to deployment is the most traditional
approach, and often the first step for organizations just starting with
application security. This approach consists of security tests that
run during the quality assurance phase. These tests are provided
by security teams or third-party vendors, and the outcomes are
delivered in bulk to developers for remediation with the expectation
that everything will be fixed prior to deploying to production.
In this traditional gate approach, SAST, DAST, IAST, and SCA are the
most commonly observed security evaluation tools. Although having
security as a gate is better than having no application security at
all, this approach causes developer friction and delays in delivering
secure applications. Late security feedback causes confusion,
manual reviews lead to bottlenecks, and scan results have a high
noise-to-signal ratio—all of which lead to developer frustration and
disrupt developer velocity.
End-to-end approach: Security integrated
into every step of the development cycle
Organizations that are more mature in application security employ
an end-to-end approach. This delivers superior results to the
traditional approach by providing developers with feedback on
their application’s security earlier (“shifting security left”), and

leveraging integration and automation capabilities throughout
the development lifecycle. However, like the shortcomings of the
traditional approach, the end-to-end approach has four main
friction points:
1.
Integrations require constant upkeep and frequently break due
with version updates.
2.
Security teams and development teams still work in silos.
3.
Automated tools don't solve the problem of false positives.
4.
Traditional tools fail to keep up with the pace of the
software ecosystem.
Relatively newer approaches to application security—including
security in the DevOps lifecycle (sometimes referred to as
DevSecOps) and shifting security left—have suggested significant
improvements to the above approaches, but drove little change
since the tools and processes themselves remained stagnant.
Part three: Developer-first
application security with GitHub
To actually drive down the number of vulnerabilities in production
code, security teams need to partner with developers in their
preferred environment and leverage their existing workflows. Putting
developers front and center for application security is the most
effective way to shift security left and succeed against the mounting
technical debt that can overwhelm even the best teams.

Using GitHub, your teams can create secure applications with a
developer-first approach, empowering your developers to share
lessons learned and easily tackle today’s application security
issues. Instead of relying on multiple tools that cause friction,
GitHub offers a unified, native, and automated solution already
in your developer workflow, and additional security code reviews
during every step of the development process. Developers get
security feedback within the development workflow with supply
chain and code security features—including code scanning,
Dependabot alerts for vulnerable dependencies and Dependabot
security updates, secret scanning, and more. You can address
security risks earlier to automate vulnerability fixes and ship more
secure applications, faster.

T H E C O M P L E T E G U I D E T O D E V E L O P E R - F I R S T A P P L I C AT I O N S E C U R I T Y 1 0
Part one: State
of application
security today

Application security leverages a system of tools, processes, and
best practices to manage application-related business risk.
Depending on the level of risk you’re willing to accept and how
critical your applications are, application security ranges from solely
being aware of the risks to having well-established processes for
quickly identifying and remediating vulnerabilities, ideally before
they make it into a production environment.
Modern software is built on open source. Ninety-nine percent
of enterprise codebases contain open source code according to
Synopsys’ 2020 Open Source Security and Risk Analysis Report.1
But as the adoption of open source components increases, so
can security risks for both your developers and security teams due
to increased exposure. For example, projects frequently inherit
vulnerabilities from unpatched open source components used
as dependencies. And the likelihood of these risks is rising, with
the 2019 State of the Software Supply Chain Report by Sonatype
reporting a “71 percent increase in confirmed or suspected open
source-related breaches in the last five years.”2
Before we dive into different approaches to application security, let’s
review some common application security concepts:
Static application security testing
(SAST)
SAST uses application source code or binary code as input, and
scans this code for known vulnerable code patterns to generate
results that identify potential vulnerabilities. SAST tools are
commonly used in early to late stages of software development,
especially prior to shipping the code to production.
P A R T O N E : S TAT E O F A P P L I C AT I O N S E C U R I T Y T O D AY
--------
1: 2020 Open Source Security and Risk Analysis Report, Synopsys
2: 2019 State of the Software Supply Chain Report, Sonatype

SAST tools run multiple analyzers to find potential vulnerabilities
across the code, but the inability to validate context and
exploitability may lead to “noisy” results. Since scan results are
based on known vulnerability patterns, these results are not highly
accurate, with many SAST tools generating false positives. Not only
are scans time-intensive, taking anywhere from hours to weeks, but
reviewing raw scan results is a labor-intensive task. Your security
team or development leads need to validate and prioritize true
positives while removing false positives. This ends up becoming the
bottleneck for traditional SAST tools.
Dynamic application security testing
(DAST)
DAST examines a target application’s code to identify its attack
surface, or application tree, and deploys the application in
a test environment to run simulated attacks. DAST tools are
commonly used during QA prior to shipping the code, as well as on
production applications.
The process generates raw scan results which point out potentially
exploitable vulnerabilities, such as those made available via the user
interface. As a result, DAST tools identify a subset of the application
layer vulnerabilities reported by a SAST tool, which are known to be
exploitable. DAST tools can also find vulnerabilities SAST tools miss,
like those related to the running environment of the application
(server, frameworks, network). This is why SAST and DAST are used
as complementary methods to comprehensively understand the
risk posture of applications. DAST tools validate attack results with
server responses they receive, so scan results need to be manually
reviewed before fixes are planned.

Integrated application security testing
(IAST)
IAST finds security vulnerabilities by installing an agent which runs
alongside the target application. IAST is commonly used during
continuous integration (CI) and quality assurance (QA) phases.
There are two variants of IAST:
Passive IAST is used for applications running in testing
environments. When the application goes through use case-based
QA tests, the agent identifies potential security vulnerabilities. This
approach finds a subset of vulnerabilities that can also be found
using SAST or DAST.
Active IAST is used for applications running in live environments
and acts as an enhancement for DAST tools. The agent is installed
on the running application and performs DAST tests against the
application. The agent can view stack trace information and can do
detailed behavior analysis on the server side, so the DAST process
and results can be improved. Active IAST helps reduce the scanning
time and validate attack results for DAST.
Runtime application security protection
(RASP)
RASP involves installing an active agent on a running application
and using this agent to protect the application at runtime. In
contrast to other AST tools, RASP tools are used against active
vulnerability exploits on applications running in production
environments. RASP agents can detect and prevent predefined

sets of vulnerabilities, but these agents may degrade application
performance, especially under heavy usage, DoS, or DDoS attacks.
Fuzzing
Fuzzing (or fuzz testing) uses automated or manual methods to
provide invalid, unexpected, or random data as inputs to running
applications in a test environment. As these inputs are sent, the
target application is continuously monitored for exceptions which
may include crashes, abnormal behavior, or potential memory
leaks. Fuzzing can provide additional information about a target
application and serves as a complementary method for DAST.
Software composition analysis
(SCA)
SCA analyzes an application to determine its third-party
components, frequently focused on open source software (OSS)
security issues and license compliance. SCA is often used in early
phases of software development.
Today’s SCA tools create an inventory of third-party components
and check these components for known vulnerabilities or other
operational risks such as license compliance. In some cases,
they also offer a library of verified and compliant components for
developers to use.
Penetration testing
Penetration testing involves automated and manual tests that aim
to test the security controls of running applications. In most cases

penetration tests only cover applications running in production, but
they can also be scoped to cover pre-production environments.
Penetration tests can be conducted by internal or external teams,
and are typically summarized in reports. The results of these
tests are already validated by the testing team, but penetration
tests require planning and take longer than automated scanning
methods. In addition to technical vulnerabilities, penetration tests
can discover faults in the logical flow or user experience of the
applications in scope.
Bug bounties
Bug bounties are crowd-sourced security testing programs which
leverage individual security researchers who get paid based on
the vulnerabilities that they discover. Bug bounties serve as a
complementary solution to all of the methods noted above, but
don’t typically provide comprehensive coverage for the security
posture of applications.
For the average organization today, application security consists of
a small set of testing tools integrated with the software development
cycle. Depending on your organization’s maturity level, tools, and
capabilities, application security may either be treated as the final
gate before deploying an application, or alternatively as a series of
integrated tests as part of the development cycle.
Let’s take a look at these two approaches and what they mean for
your developers.

Part two:
Traditional vs.
end-to-end
security

The traditional approach
Having security as a gate prior to deployment is a common
approach, and often the first step for organizations just starting
with application security. This “traditional” approach consists of
a single security test or a series of security tests that take place
during the quality assurance phase. These security tests are run by
security teams or third parties, and the outcomes of the security
results are delivered in bulk to developers for remediation. The tests’
findings are then expected to be fixed before the application goes
into production.
Application security as a gate
P A R T T W O : T R A D I T I O N A L V S . E N D -T O - E N D S E C U R I T Y
Project
configuration
Ship
Project
inception
SAST
SCA
DAST
IAST
SAST
DAST
SCA
IAST
PR
Merge
Code review
Commit
CI / Testing
Code / Test
CD
QA
Integration
testing

In this traditional gate approach, teams most commonly use SAST,
DAST, IAST, and SCA tools.
Although having security as a gate is better than having no
application security at all, it causes developer friction and delays
delivering secure applications. This is due to three main reasons:
1.
Late security feedback causes confusion. Security feedback
that comes at a later stage in development (often weeks after
the code’s creation) means that developers have already moved
on to the following sprint or the next project, so the vulnerable
code in question is no longer top of mind. It can take a while for
developers to refamiliarize with the code and context, and the
fixes often require additional sprint planning, potentially delaying
current projects. “More than 70 percent of all flaws remain
one month after discovery and nearly 55 percent remain three
months after discovery” per the State of Software Security Report
Volume 10 by Veracode.3
2.
Scan results have a high noise-to-signal ratio. Traditional
application security tools generate multiple false positives for
every true positive, so reviewing scan results is a challenging
task. These reviews are generally done by security teams who
have limited knowledge about the scanned projects, which
makes auditing scan results difficult and labor-intensive. Another
approach is to push raw scan results to developers without
reviews, but this puts the burden of evaluation onto developers,
deprioritizing their effort to actually fix the issue.
In both cases, a considerable amount of false positives make
their way to developers as items to be fixed, causing confusion
and frustration.
--------
3: State of Software Security Report Volume 10, Veracode

3.
Manual reviews cause bottlenecks. When scan results are
generated by automated tools, they still require manual review
to identify true positives and eliminate false positives. Security
teams are greatly outnumbered by developers and they simply
can’t keep up with the sheer volume of raw scan results that need
their attention. Manual reviews can take days and even weeks for
the average project, creating a bottleneck and delays in project
timelines. Delays can be even more frustrating in cases where
manual review results don’t meet expectations. In most cases,
delayed security results mean teams have to ship releases with
known vulnerabilities, with no time to fix these issues to meet
project timelines.
Another downside of traditional security is that if a project isn’t
a priority, it won’t get manual reviews. “Raw” scan results may
also be shared directly with developers, which are non-validated
scan results with a high false positive (non-finding) ratio. Since
these results can quickly become frustrating and developers
can become desensitized to so many false positives, raw scans
are either turned off or their results get ignored. Either option
adds more risk to your organization. If security issues aren’t
addressed in time, they can become a legal liability—like if a
security issue is found to be a source of a data breach, or if not
remediating a known issue is a breach of one (or more) of your
customer contracts.
The end-to-end approach
Organizations that are more mature in application security
employ an end-to-end approach, which starts in earlier stages of
development and has more points of interaction throughout the
development lifecycle.

End-to-end approach
The end-to-end approach provides earlier security feedback to
developers and leverages integration and automation capabilities of
security tools. But like traditional security, end-to-end security still
has several friction points:
1.
Integrations require a lot of upkeep and frequently break
because of version updates. Although security tools are
integrated with the development process, these integrations
break often. Developers have to drop their current tasks to
address a security issue and log into another portal to deal with
a different tool or system. Security feedback lacks context and
context-switching remains a challenge. The user experience
becomes problematic and inefficient for developers.
2.
Security teams and development teams continue to
work in silos. Changing your tooling isn’t enough to change
Project
configuration
IDE plugins
IAST
SCA
Ship
Project
inception
SAST
SCA
SAST
SCA
DAST
IAST
SAST
DAST
SCA
Penetration
testing
Bug bounty
DAST
PR
Merge
Code review
Commit
CI / Testing
Code / Test
CD
QA
Integration
testing

your processes. Silos between the security and application
development teams still have to be addressed for end-to-
end security to work. Integrating tools streamlines part of the
application security process, but this approach again falls
short of nurturing more collaboration between security and
development teams.
Security teams also still act as reviewers for testing results. For
example, every commit on the main branch gets scanned and
new alerts are sent to the security team for review. The security
team still has to triage and send issues back to developers to
fix, and the team likely still has a gating process on release. This
is a better approach than having security tests as a gate since
some things get caught early, but these teams still lack common
processes and platforms to collaborate. With silos and poor
communication, issues are pushed back and forth between
teams, often leading to delays and sometimes conflict.
3.
Automating traditional tools doesn’t solve the false positive
problem. It’s exciting to think about automated application
security tools. But in reality, automating scans and pushing
results to an issue tracker leads to a flood of non-actionable
issues. Here the problem is false positives and developers
becoming desensitized to noise. With too many alerts, developers
ignore test results (and mark them all as “false positives” or
“won’t fix”). Traditional security tools lack the customizability to
adjust sensitivity or improve results over time, so when results are
pushed into developer flows, developers switch these tools off.
4.
Traditional tools fail to keep pace with the software ecosystem.
Today’s software ecosystem consists of open source, new
programming languages, new frameworks, and emerging tools
that evolve at a breakneck pace. Since traditional commercial
tools are created, updated, and supported by small vendor teams,

they struggle to keep up. There’s also very limited communication
between these vendors and the developer community, requiring
research teams to proactively look for OSS vulnerabilities—an
unscalable task with 100 million-plus public repositories. As
a result, most commercial tools do well in a few aspects of
application security or limit their support to a small part of the
software ecosystem. This means your developers and security
teams either have to work with multiple tools and vendors for a
single use case, or invest in home-grown solutions to fill the gaps
that your commercial tools create.
DevSecOps and shifting left
Relatively newer approaches to application security—including
DevSecOps and shifting security left—have suggested significant
improvements to both traditional and end-to-end security. However,
they’ve driven little change since the tools and processes remain
mostly the same.
Even with DevSecOps, traditional and end-to-end security
approaches still share common problems:
1. High friction between developers and security teams,
2. Applications frequently shipped with known vulnerabilities (83
percent of applications have one security flaw on initial scan and
two out of three applications fail to pass tests based on OWASP
Top 10 and SANS 253
),
3. Low fix rates for discovered vulnerabilities (only 56 percent of
--------

security flaws are fixed, with 24 percent of high-severity flaws left
unfixed by developers3
), and
4. Long exposure periods for detected issues (the median time to
fix security flaws is 59 days3
).
With all of these challenges combined, it’s little surprise that web
applications have been reported as the main cause of security
breaches over the last five years.4
--------
4: 2016, 2017, 2018, 2019 and 2020 Data Breach Investigation Reports, Verizon

Part three:
Developer-first
application security

Developer-first, community-powered security
with GitHub
Unless security issues can be identified and fixed by your
developers early in the development lifecycle, technical debt will
continue to be a challenge for your software ecosystem. And like
many other challenges, application security problems are easiest
and most cost-effective to solve at the source. To actually drive
down the number of vulnerabilities in production code, we need to
partner with developers in their preferred environment and use their
existing workflows.
There’s only one way to shift security left and succeed against
overwhelming technical debt: Putting developers front and
center for application security.
By prioritizing developers and giving them the tools to work in
the most efficient way, GitHub takes responsibility for making
the software we all rely on more secure. GitHub creates secure
applications with a community-powered approach that addresses
feedback early and often from developers; empowers researchers
to enhance and embellish search capabilities; and crowd-sources
bug bounty testing programs. Instead of relying on multiple tools
that cause friction in the process, GitHub offers a unified, native,
and automated solution within the developer workflow. You can
address security risks earlier, automate vulnerability fixes, and have
better security governance to build and protect applications.
P A R T T H R E E : D E V E L O P E R - F I R S T A P P L I C AT I O N S E C U R I T Y W I T H G I T H U B

How to improve your project’s security
with GitHub
1. Start with security in mind
Reviewing security requirements and identifying potential risks with
your project prior to implementation are critical steps for preventing
expensive vulnerability fixes. Here are a few ways to put them
into practice:
Apply security best practices for project configuration
Configuring your project to match security best practices can
prevent a lot of problems. Reviewing accounts and access settings
(including roles and responsibilities, two-factor authentication, git
over SSH, managing teams, integrations, and projects) along with
setting a SECURITY.md vulnerability disclosure and reporting policy
can go a long way.
Model threats for the project
Software threat modeling is the set of activities that helps identify
the potential threats, threat actors, and vulnerable components in
a project. Threat modeling requires analyzing the business logic
and flow of sensitive data through library APIs like source and sink.
Source is the part of code where data is ingested, and sink is the
part of code where data flow is completed.
CodeQL is the industry-leading semantic code analysis engine
that lets you query code as though it were data—making it easy to
discover a bad pattern and then find similar occurrences across
your entire codebase. Behind the scenes, CodeQL adaptive threat

modeling semi-automatically boosts your JavaScript security
queries with machine learning to find more security vulnerabilities
and improve taint specifications. Taint specifications capture the
role of library APIs—source and sink—and are a critical component
of any taint analyzer that aims to detect security violations based
on information flow. A boosted query then produces a ranked list of
additional results for you to review. With adaptive threat modeling,
your JavaScript and TypeScript queries will identify more security
problems. For example, using this technique GitHub Security Lab
was able to find 118 new NoSQL injection vulnerabilities across 50
JavaScript projects.
Customize static scans
Custom queries provide a powerful way for static application
security testing solutions to detect security issues that may not be
covered by the standard rule and/or query sets. These issues can be
specific to your codebase or to patterns that are considered issues
within context. CodeQL lets you add custom rules easily with a SQL-
like query language to focus on issues that matter for your project.
You can also configure the CodeQL engine to run the standard
query set and custom queries for static scans for the lifetime of
your project.
2.
Secure every step of the development
process
Traditional security approaches have shown that if solutions don’t
empower developers to find and fix issues early, they’re likely to fail.
We can also tell that scanning projects for vulnerabilities periodically
doesn’t stop technical debt from mounting up. As a result, technical
debt continues to grow and cause security defects, along with other
problems for your team.

GitHub delivers additional security code reviews for every step of
the development process with native solutions. Developers get
security feedback within the development workflow with supply
chain and code security features—including Dependabot alerts for
vulnerable dependencies, secret scanning, and more.
Secure the supply chain
A software supply chain is anything that goes into—or affects—your
codebase, from development to your CI/CD pipeline to production.
Within your supply chain, software dependencies are everywhere.
It’s normal for your projects to use open source dependencies that
you didn’t write yourself. The 2019 State of the Software Supply
Chain Report by Sonatype reports that anywhere from 85 to 97
percent of enterprise codebases use open source.2
If any of your dependencies has a vulnerability, chances are your
application has a vulnerability as well. Being able to leverage
the work of thousands of open source developers means that
thousands of strangers effectively could have control over your
production code. Both an innocent mistake or malicious attack
to your supply chain can have a widespread impact on your
codebase—making security both proactive and reactive. Securing
your software supply chain is an ongoing process of knowing what’s
in your environment, managing your dependencies, and monitoring
your supply chain.
Dependency graph, dependency insights,
and Dependabot
With features like the dependency graph, dependency insights,
--------
2: 2019 State of the Software Supply Chain Report, Sonatype

Dependabot alerts and Dependabot security updates, developers
can easily see which dependencies they use and open pull
requests with fixes to resolve them automatically. Once you’re
aware of your dependencies, Dependabot alerts notify you of
repositories affected by a newly discovered vulnerability. To do this,
GitHub compares the information in the dependency graph to the
information in the GitHub Advisory Database. A Dependabot alert
can be sent when you’ve added a new dependency (we check for
vulnerabilities in that dependency), or when a new vulnerability is
discovered (we alert any repositories that are vulnerable). The alert is
sent to repository owners by default.
Dependabot security updates will send you a pull request to update
a dependency to the minimum version that resolves a known
vulnerability—that is, the first version with the patch. This suggested
change to the lock file happens automatically based on alerts.
Secure code
Custom code delivers application logic and unique capability for
projects. It’s developed by the developers or vendors on your project
team. Securing custom code within projects is another critical
step in shipping secure applications and preventing potential zero
day vulnerabilities.
Code scanning
Code scanning is a developer-first SAST product that’s built into
GitHub. After it’s configured, it scans every code change in your
repository for security vulnerabilities and flags them in the developer
workflow. This makes it easy to find security vulnerabilities in your
code before they ever reach production.

With code scanning enabled, every `
git push` is scanned for new
potential security vulnerabilities, and results are displayed directly
in your pull request. By default, code scanning uses CodeQL,
which has an unmatched record finding real vulnerabilities. It
includes 2,000-plus CodeQL queries written and open sourced by
the GitHub Security Lab and leading security researchers to find
potential vulnerabilities in your code with minimal configuration.
Code scanning can also be augmented and expanded to
incorporate other commercial and open source scanning
technologies like Anchore Container Scan, RuboCop Linting,
ShiftLeft Scan, Open Source Static Analysis Runner (OSSAR)—
which allows running multiple open source security static analysis
tools—and others.
Secret scanning
GitHub has provided secret scanning for public repositories,
including API keys and authentication tokens, since 2018. Secret
scanning protects our partners and community from unauthorized
use of the services protected by those secrets.
As part of GitHub Advanced Security, we’re bringing the same
lightning-fast scanning engine and broad set of 27 partners (a
growing list including all the major cloud providers and many
common SaaS providers) to private repositories, so you can catch
secrets as soon as they’re checked in. Repository administrators
will be notified about any commit that contains a secret, and can
quickly view all detected secrets in the repository’s Security tab.
Third-party security capabilities through GitHub Actions
GitHub Actions makes it possible to automate, customize, and

execute your software development workflows in the same place
you code. You can discover, create, and share actions to perform
any job you’d like, including CI/CD, and combine actions into a
completely customized workflow. Since individual actions are
reusable as code, it’s easy to take advantage of the collective
knowledge of millions of other developers and security teams, just
as you do in your applications.
Actions serves as an open platform to easily integrate with third-
party security tools. Some of the current integrations include
OWASP ZAP, which supports both baseline and full DAST scans,
SonarCloud Scan, Snyk, and many others.
3.
Improve collaboration and get continuous
security feedback
Making security an integral part of the developer workflow on
GitHub opens up secure collaboration for all: within individual
teams, across your organization, and within the community.
Collaborate with security during all stages
of development
Getting security input at the pull request level allows developers to
have early feedback with the right context at the right time, so they
can fix security issues while they’re still working on the same portion
of the code. Having this enriched view of the security issues also
empowers security teams to become a part of the triage and fix
process by providing their input on GitHub where and when code
is created. When your development and security teams are aligned,
they can prioritize issues more efficiently, discuss optimal fixes, and
validate results together.

Collaborate between developers, security teams, and
the community
Increased collaboration between development and security
teams—plus the customizable nature of CodeQL—helps teams
make the most of existing CodeQL queries and create new queries
to address their projects’ needs. Development teams can identify
specific needs for queries, while security champions within
development teams or security teams can customize existing
CodeQL queries or create new ones. Once you create customized
queries, you can then share them across your organization. Your
teams can also opt to contribute the queries they’ve made to the
open sourced query set for the community to use.
Alerting the community about security vulnerabilities in your
projects is another way security teams, security researchers,
developers and the community can collaborate. You can publish
security advisories natively on GitHub to quickly notify everyone
using the project, and initiate the process to fix these issues. We’ll
review each published security advisory, add it to the Advisory
Database, and may use the security advisory to send Dependabot
alerts to affected repositories.
Collaborate within the community:
A community- driven approach
The standard CodeQL libraries and queries that power GitHub
code scanning are open source and available for anyone to review
and contribute—just open a pull request. Since GitHub’s security
capabilities are open source, when you contribute or review a query,
you’re also helping secure the software we all rely on.

Conclusion

It’s no exaggeration: Open source software has changed the
world. Many of today’s most innovative applications are built
on code anyone can freely access and contribute to. Just
like open source teams collaborate on shared projects, the
only way to combat technical debt with today’s increasing
code volume and velocity is to solve security issues together.
Community-powered security can help security experts share
lessons learned and provide better ways to solve today’s
application security issues.
Developer-focused, community-centric security also makes
it possible to find and fix issues earlier, while improving
collaboration with both your own organization and the greater
open source community. Whether you want to stay up to date
with the larger software ecosystem or be aware of the latest
threats, GitHub allows you to contribute to the development of
security best practices that benefit and empower everyone.
C O N C L U S I O N

W R I T T E N B Y G I T H U B W I T H ❤
Questions about application security?
Learn more at github.com/learn/security
or contact our Sales Team

Other documents randomly have
different content

F
CAP. CV.
Of the Kingedome of Ryboth.
ROM this yle men go another kyngdome that is called Riboth,
and that is also under ye
great Caan. This is a good countrey and
plentious of corne, wine other things, men of this lande haue no
houses but they dwell in tentes made of tree. And the principall citie
of the countrey is all blacke made of black stones and white and all
the streetes are paved with such stones and in the citie is no man so
hardy to spil blood of man ne beast, for worship of a mawment1
that
is worshiped there. In that citie dwelleth the Pope of their lawe, that
they call Lopasse, and he giveth all dignities benefices that fall to
ye
mawmet. And men of religion and men that haue churches in that
countrey are obedient to him as men here to the pope. In this yle
they haue a custome through all the countrey that when a mans
father is dead they wil do him great worship, they send after all his
friends, religious priests and many other, and they beare the body to
an hill with great Joy and myrth, and whan it is there, the greatest
prelate smiteth of his head, laieth it upon a great plate of gold, or
silver, and giveth it to his sonne and his son taketh it to his other
friends, singing and sayinge many orysons,2 and then the prestes
and the religious men cut the flesh of3
the body in peces and say
orysons, and the byrds of the countrey come thether, for they know
well the custome, and they flye about them as they were egles and
other birds that eate flesh, and the priestes cast the pieces unto
them, and they beare it away a little from thence and then they eate
it, and as priestes in our countrey sing for soules subvenite sancti
dei and so forth, so those prestes ther syng with high voyce in their
language in this maner wyse. Se and beholde how good and
gracious a man this was, that ye aungels of God come for to fetch

him beare him into Paradise. And then thinketh ye
son of the same
man that he is greatly worshipped when birds haue eaten his father,
and where are most plenty of byrds, there is most worship. And then
cometh the sonne home with all his friendes, and maketh them a
great feast, the sonne maketh cleane his fathers head and giveth
them drynke thereof, the fleshe of the head he cutteth of, and
giveth it to his moste speciall fryends, some a lyttle, some a lyttle,
for deynty. And in remembrance of this holy man that the birds haue
eaten, the sonne doth make a cuppe of the scalpe4
thereof
drinketh he all his life, in remembrance of his father.
1: A puppet or doll, or mammet—an idol—probably so called as a
contraction for Mahomet.
2: Prayers.
3: Off.
4: Skull.

A
CAP. CVI.
Of a rych man that is neyther king, prince, duke nor erle.
ND from this men go ten journeys through the land of the great
Caan, which is a full good yle a great kingdom the king is ful
mighty. And in this yle is a rich man which is no king, prince, Duke
nor Erle, but he hath eche yere cccc1 thousand horses charged2 with
ryce and corne, and he hath a noble a rich life after the maner of
the countrey, for he hath L damosels that serve him every day at his
meate bed and do what he wil. And when he sytteth at the table
they bring him meat, at eche time fiue meates togither, and they
sing in the bringing a song, and they cut his meate and put it in his
mouth, and he hath righte long nayles on his hands, that is a great
nobility in that countrey therefore they let theyr nayles grow as
long as they may,3
and some let them growe so long that they come
about theyr handes and yt
is a great nobility gentry, and the
gentry of a woman is to haue small fete, and therefore anon as they
are borne, they binde their feete so straight that they cannot wax
halfe as they shoulde. And he hath a full faire palaice, rich, wher
he dwelleth, of which the wall is two myle about, there is many
faire gardeins, and all the pavement of the hal, chambres, is of
gold silver, and in the midst of one of these gardeins is a lyttle hyl,
whereon is a place made wyth toures and pynacles all of golde, and
there he wyll syt often to take the ayer and disport, for it is made for
nothing else. From this land men may go through ye
land of the
great Caane.
1: Other editions say 300,000.
2: Loaded.

3: Similar to the Chinese custom of the upper classes.

A
CAP. CVII.
How all these landes yles and kingdomes, and the men
therof afore rehersed, haue some of the articles of our faith.
ND ye shall understand that all these men folke that haue
reason yt
I haue spoken of, haue some articles of our faith, all1 if
they be of divers lawes and divers beleves, yet they haue some good
poynts of our fayth, they beleve in God of kinde as theyr
prophecie sayth, Et metuent eum omnes fines terræ, That is to say,
And all endes of the earth shall dread him. And in another place,
Omnes gentes servient ei, That is to say, All folk shall serve him, but
they cannot speak parfitly but as theyr kyndly wit teacheth them,
neither of the Son nor of the Holy Ghost can they speake, but they
can speake well of the Byble, and specially of Genesis, and of the
bokes of Moyses. And they say that those creatures yt
they worship
are no gods, but they worship them for great vertue that is in them
which may not be without special grace of God, of simulacre and
ydoles, they say that all men haue simulacres, and that, say they, for
us christen men haue ymages of our Lady other, but they wot not
that we worship not the ymages of stone nor of wood, but the
saynts of whome they are made, for as the letter teacheth clarkes
how they shal beleve, so ymages and paynture teacheth lewde2
men. They say also that the aungell of God speaketh to them in their
ydoles do miracles, they say soth,3 but it is the evil aungell that
doth myracles to maintaine them in their ydolatrie.
1: Even.
2: Unlearned.

T
CAP. CVIII.
How John Maundevyl leveth many mervailes unwrytten
the cause wherefore.
HERE are many other countreys where I haue not yet ben nor
sene therefore I can not speke properly of them. Also in
countreys where I haue bene are many marvailes that I speke not
of, for it were to long a tale and therefore hold you payd at this time
yt
I haue sayd, for I will say no more of mervailes that are there, so
that other men that go thither may fynde ynough for to say that I
haue not tolde.

A
CAP. CIX.
What time John Maundevil departed out of England.
ND I John Maundevil that went out of my countrey and passed the
sea, the yeare of our lord MCCCXXII and I haue passed through
many landes and yles and countreys, and now am come to rest. I
haue compyled this boke and do wryte it the yeare of our Lord
MCCCLXVI at XXXIV yeare after my departing from my countrey, for
as much as many men beleve not that they see with theyr eyen, or yt
they may conceive know in their mynde, therefore I made my way
to Rome in my coming homewarde, to shew my boke to the holy
father the pope,1
and tell him of the mervayles yt
I had sene in diverse
countreys; so that he with his wise counsel wold examine it, with
diverse folke yt
are at Rome, for there dwell men of all nations of the
world, and a lytle time after when he his counsel had examined it all
through, he sayde to me for a certayne that it was true for he sayd he
had a boke of latin contayning all that and much more, of ye
which
Mappa Mundi is made, the which boke I saw, therefore the pope
hath ratyfied confirmed my boke in all poyntes. And I pray to all
those that rede this boke, that they will pray for me and I shall pray
for them, all those that say for me our Lord's prayer that God
forgive me my sinnes, I make them parteners graunt them part of
all my good pylgrimages and other good dedes which I ever dyd or
shall do to my lyves ende I pray to God of whome all grace cometh,
that he will, all the readers and hearers that are christen, fulfil with his
grace, and saue them body and soule bring them to his Joy that
euer shall last. He that is in the Trinitie, the Father, the Sonne, and the
Holy Ghost, that liveth raigneth God without ende
Amen

1: Urban V.
Imprinted at London in Breadstreat at the nether
ende
by Thomas East. An 1568
The 6 day of October

Here beginneth the journall of Frier Odoricus,
one of the order of the Minorites, concerning
strange things which hee sawe among the
Tartars of the East.
LBEIT many and sundry things are reported by divers
authors concerning the fashions and conditions of this
world: notwithstanding I frier Odoricus of Friuli, de
portu Vahonis being desirous to travel unto the foreign
and remote nations of infidels, sawe and heard great
and miraculous things, which I am truly able to avouch. First of al
therefore sayling from Pera by Constantinople, I arrived at
Trapesunda.1 This place is right commodiously situate, as being an
haven for the Persians and Medes, and other countries beyonde the
sea. In this lande I behelde with very great delight a very strange
spectacle, namely a certain man leading about with him more than
foure thousande partriges. The man himselfe walked upon the
grounde, and the partriges flew in the aire, which he ledde unto a
certaine castle called Zavena, being three days journey distant from
Trapesunda. The saide partriges were so tame, that when the man
was desirous to lie downe and rest, they would all come flocking
about him like chickens. And so hee led them unto Trapesunda, and
unto the palace of the Emperour, who tooke as many of them as he
pleased, and the reste the saide man carried unto the place from
whence he came. In this citie lyeth the body of Athanasius, upon the
gate of the citie. And then I passed on further unto Armenia major,
to a citie called Azaron,2 which had been very rich in olde time, but
nowe the Tartars haue almost layde it waste. In the saide citie there
was abundance of bread and flesh, and of all other victuals except
wine and fruits. This citie also is very colde, and is reported to be
higher situated, then any other city in the world. It hath most

holesome and sweete waters about it: for the veines of the saide
waters seeme to spring and flow from the mighty river of Euphrates,
which is but a dayes journey from the saide city. Also, the saide citie
stands directly in the way to Tauris.3 And I passed on unto a certaine
mountaine called Sobissacalo. In the foresaide countrey there is the
very same mountaine whereupon the Arke of Noah rested; unto the
which I would willingly haue ascended, if my company would haue
stayed for me. Howbeit the people of that countrey report, that no
man could euer ascend the saide mountaine, because (say they) it
pleaseth not the highest God. And I travailed on further unto Tauris
that great and royal city, which was in olde time called Susis. This
city is accompted for traffique of merchandize the chiefe citie of the
world: for there is no kinde of victuals, nor any thing else belonging
unto merchandize, which is not to be had there in great abundance.
This citie stands very commodiously: for unto it all the nations of the
whole worlde in a maner may resort for traffique. Concerning the
saide citie, the Christians in those parts are of opinion, that the
Persian Emperour receives more tribute out of it, then the King of
France out of all his dominions. Neare unto the saide citie there is a
salt-hill yeelding salt unto the city: and of that salt ech man may
take what pleaseth him, not paying ought to any man therefor. In
this city many Christians of all nations do inhabite, over whom the
Saracens beare rule in all things. Then I traveiled on further unto a
city called Soldania,4
wherein the Persian Emperour lieth all Sommer
time: but in Winter hee takes his progresse unto another city
standing upon the sea called Baku.5 Also the foresaide city is very
great and colde having good and holesome waters therein, unto the
which also store of marchandize is brought. Moreover I travelled
with a certaine company of Caravans toward upper India: and in the
way, after many days journey, I came unto the citie of the three wise
men called Cassan,6 which is a noble and renowned city, saving that
the Tartars haue destroyed a great part thereof, and it aboundeth in
bread, wine, and many other commodities. From this citie unto
Jerusalem (whither the three foresaid wisemen were miraculously
led) it is fifty days journey. There be many wonders in this citie also,

which for brevities sake, I omit. From thence I departed unto a
certain city called Geste, whence the sea of sand is distant one
dayes journey, which is a most wonderful and dangerous thing. In
this city there is abundance of all kinds of victuals and especially of
figs, raisins, and grapes: more (as I suppose) then in any part of the
whole world besides. This is one of the three principall cities of all
the Persian Empire. Of this city the Saracens report, that no Christian
can by any means live therein above a yeere. Then passing many
dayes journey on forward, I came unto a certain city called Comum7
which was a huge and mightie citie in olde time, conteyning well
nigh fiftie miles in circuite, and hath done in times past great
damage unto the Romanes. In it there are stately palaces altogether
destitute of inhabitants, notwithstanding it aboundeth with great
store of victuals. From hence travailing through many countreys, at
length I came unto the land of Job called Hus, which is full of all
kinde of victuals and very pleasantly situated. Thereabouts are
certaine mountaines having good pastures for cattell upon them.
Here also Manna is found in great aboundance. Four partriges are
here solde for lesse than a groat. In this countrey there are most
comely olde men. Here also the men spin and card, and not the
women. This land bordereth upon the North part of Chaldea.
1: Trebizonde.
2: Erzeroum.
3: Tauris, a city of Persia.
4: Or Sultania.
5: The Caspian Sea.
6: Or Cassibin.
7: Como.

F
Of the maners of the Chaldeans, and of India.
ROM thence I traveled into Chaldæa, which is a great kingdome
and I passed by the tower of Babel. This region hath a language
peculiar unto itselfe, and there are beautiful men and deformed
women. The men of the same countrey used to haue their haire
kempt, and trimmed like unto our women: and they weare golden
turbants upon their heads richly set with pearle, and pretious stones.
The women are clad in a course smock onely reaching to their knees
and having long sleeves hanging downe to the ground. And they goe
barefooted, wearing breeches which reach to the ground also. They
weare no attire upon their heads, but their haire hangs disheaveled
about their eares: and there be many other strange things also.
From thence I came into the lower India, which the Tartars overran
wasted. And in this countrey the people eat dates for the most
part, whereof 42 li are there sold for lesse than a groat. I passed
further also many dayes journey unto the Ocean Sea the first
lande where I arrived, is called Ormes,1 being well fortified, and
having great store of merchandize and treasure therein. Here also
they use a kinde of Bark or shippe called Jase, being compact
together onely with hempe. And I went on board into one of them,
wherein I could not finde any yron at all, and in the space of 28 days
I arrived at the city of Thana,2 wherein foure of our friers were
martyred for the faith of Christ. This countrey is well situate having
abundance of bread and wine, and of other victuals therein. This
Kingdome in olde time was very large and under the dominion of
King Porus, who fought a great battell with Alexander the great. The
people of this countrey are idolaters worshipping fire, serpents and
trees. And ouer all this land the Saracens do beare rule, who tooke it
by maine force, and they themselues are in subjection unto King
Daldilus. There be divers kinds of beasts, as namely blacke lyons in
great abundance, and apes also, and monkeis, and battes as bigge

as our doves. And there are mise as bigge as our countrey dogs, and
therefore they are hunted with dogs, because cats are not able to
encounter them. Moreouer in the same countrey every man hath a
bundle of great boughs standing in a water-pot before his doore,
which bundle is as great as a pillar, and it will not wither, so long as
water is applied thereunto: with many other novelties and strange
things, the relation whereof would breed great delight.
1: Ormus.
2: Thana, whereof Frederick Cæsar maketh mention.

M
How peper is had: and where it groweth.
OREOUER, that it may be manifest how peper is had, it is to be
understood that it groweth in a certaine kingdome whereat I
myself arrived, being called Minibar,1 and it is not so plentifull in any
other part of the worlde as it is there. For the wood wherein it
growes conteineth in circuit 18 dayes journey. And in the said wood
or forrest there are two cities one called Flandrina,2 and the other
Cyncilim. In Flandrina both Jewes Christians doe inhabite,
betweene whom there is often contention and warre: howbeit the
Christians overcome the Jewes at all times. In the foresaid wood
pepper is had after this maner: first it groweth in leaves like unto
pot-hearbes, which they plant neere unto great trees as we do our
vines, and they bring forth pepper in clusters, as our vines doe yeeld
grapes, but being ripe, they are of a green colour, and are gathered
as we gather grapes, and then the graines are layd in the Sunne to
be dried, and being dried are put into earthen vessels: and thus is
pepper made and kept. Now, in the same wood there be many
rivers, wherein are great store of Crocodiles, and of other serpents,
which the inhabitants of that countrey do burne up with strawe and
with other dry fewel, and so they go to gather their pepper without
danger. At the South End of the said forrest stands the city of
Polumbrum,3
which aboundeth with marchandize of all kinds. All the
inhabitants of that countrey do worship a living oxe, as their god,
whom they put to labour for sixe yeres, and in the seventh yere they
cause him to rest from al his worke, placing him in a solemne and
publique place: and calling him an holy beast. Moreouer they use
this foolish ceremonie: Every morning they take two basons, either
of silver or of gold, and with one they receive the urine of the oxe,
and with the other his dung. With the urine they wash their face,
their eyes, and all their fiue senses. Of the dung they put into both
their eyes, then they anoint the bals of their cheeks therewith, and

thirdly their breast: and then they say that they are sanctified for all
that day: And as the people doe, euen so doe their king and
Queene. This people worshippeth also a dead idole which from the
navel upward, resembleth a man, and from the navel downward an
oxe. The very same Idol delivers oracles unto them, and sometimes
requireth the blood of fourtie virgins for his hire. And therefore the
men of that region do consecrate their daughters and their sonnes
unto their idols, euen as Christians do their children unto some
Religion or Saint in heaven. Likewise they sacrifice their sonnes and
their daughters, and so, much people is put to death before the said
Idol by reason of that accursed ceremony. Also, many other hainous
and abominable villainies doeth that brutish beastly people commit:
and I saw many more strange things among them which I meane
not here to insert. Another most vile custome the foresaide nation
doeth retaine: for when any man dieth they burne his dead corpse
to ashes: and if his wife surviveth him, her they burne quicke,
because (say they) she shall accompany her husband in his tilthe
and husbandry, when he is come unto a new worlde. Howbeit the
said wife having children by her husband, may if she will, remaine
still alive with them, without shame or reproche: notwithstanding,
for the most part, they all of them make choice to be burnt with
their husbands. Now, albeit the wife dieth before her husband, that
law bindeth not the husband to any such inconvenience but he may
marry another wife also. Likewise, ye said nation hath another
strange custome, in that their women drink wine, but their men do
not. Also the women haue the lids brows of their eyes beards
shaven, but the men haue not: with many other base and filthie
fashions which the said women do use contrary to the nature of
their sexe. From that kingdome I traveiled 10 daies journey unto
another kingdome called Mobar,4 which containeth many cities.
Within a certaine church of the same countrey, the body of S.
Thomas the Apostle is interred, the very same church being full of
idols: and in 15 houses round about the said Church there dwell
certaine priests who are Nestorians, that is to say, false, and bad
Christians and schismatiques.

1: Malabar.
2: Or Alandrina.
3: Query, whether this is not Kaulam or Ballád-ul-Falfal, the Pepper
Country, or Malabar, latinized into Columbum or Columbus.
4: Malabar.

I
Of a strange and uncouth idole: of certaine
customes and ceremonies.
N the kingdome of Mobar there is a wonderfull strange idole,
being made after the shape and resemblance of a man, as big as
the image of our Christopher, consisting all of most pure and
glittering gold. And about the necke thereof hangeth a silke riband,
ful of most rich precious stones, some one of which is of more
value than a whole kingdome. The house of this idol is all of beaten
gold, namely the roofe, the pavement, and the sieling of the wall
within and without. Unto this idol the Indians go on pilgrimage, as
we do unto St. Peter. Some go with halters about their necks, some
with their hands bound behind them, some with knives sticking on
their armes or legs: and if after their peregrination, the flesh of their
wounded arme festereth or corrupteth, they esteeme that limme to
be holy, thinke that their God is wel pleased with them. Neare
unto the temple of that idol is a lake made by men in an open and
common place, whereinto the pilgrimes cast gold, silver and precious
stones, for the honour of the idol and the repairing of his temple.
And therefore when anything is to be adorned or mended, they go
unto this lake taking up the treasure which was cast in. Moreouer at
euery yerely feast of the making or repairing of the said idol, the
king and queene, with the whole multitude of the people, all the
pilgrimes assemble themselues, placing the said idol in a most
stately rich chariot, they cary him out of their temple with songs,
with all kinds of musical harmonie, and a great companie of
virgins go procession-wise two and two in a rank singing before him.
Many pilgrims also put themselves under the chariot wheeles, to the
end that their false god may go ouer them, and al they ouer whom
the chariot runneth, are crushed in pieces, divided asunder in the
midst, and slaine right out. Yea, in doing this, they think
themselves to die most holily securely, in the service of their god.

And by this meanes every yere, there die under the said filthy idol,
mo then 500 persons, whose carcases are burned, and their ashes
are kept for reliques, because they died in that sort for their god.
Moreover they haue another detestable ceremony. For when any
man offers to die in the service of his false god, his parents all his
friends assemble themselues together with a consort of musicians,
making him a great solemne feast: which feast being ended, they
hang 5 sharpe knifes about his neck carrying him before the idol
so soone as he is come thither, he taketh one of his knives crying
with a loud voice, For the worship of my god do I cut this my flesh,
and then he casteth the morsel which is cut, at ye
face of his idol:
but at the very last wound wherewith he murthereth himselfe, he
uttereth these words: Now do I yeeld myself to death in the behalfe
of my god and being dead his body is burned, is esteemed by al
men to be holy. The king of the said region is most rich in silver,
gold, and precious stones, there be the fairest unions in al the
world.
Traveling from thence by the Ocean sea 50 daies journey southward,
I came unto a certaine land named Lammori,1
where, in regard of
extreeme heat, the people both men and women go stark-naked
from top to toe: who seeing me apparelled, scoffed at me, saying
that God made Adam and Eve naked. In this countrey al women are
common, so that no man can say, this is my wife. Also when any of
the said women beareth a son or a daughter, she bestowes it upon
anyone that hath lien with her, whom she pleaseth. Likewise al the
land of that region is possessed in common, so that there is not
mine thine, or any propriety of possession in the division of lands:
howbeit euery man hath his owne house peculiar unto himselfe.
Mans flesh, if it be fat, is eaten as ordinarily there as beefe in our
countrey. And albeit the people are most lewd, yet the countrey is
exceeding good, abounding with al commodities, as fleshe, corne,
rise, silver, gold, wood of aloes, Camphir, and many other things.
Marchants coming unto this region for traffique do usually bring with
them fat men, selling them unto the inhabitants as we sel hogs, who

immediately kil and eat them. In this island towards the south, there
is another kingdome called Simoltra,2 where both men and women
marke themselves with red-hot yron in 12 sundry spots of their
faces: and this nation is at continual warre with certaine naked
people in another region. Then I traveled further unto another island
called Java, the compasse whereof by sea is 3000 miles. The king of
this Iland hath 7 other crowned kings under his jurisdiction. The said
Island is throughly inhabited is thought to be one of the principall
Ilands of ye
whole world. In the same Iland there groweth great
plenty of cloves, cubibez, and nutmegs, and in a word all kinds of
spices are there to be had, and great aboundance of all victuals
except wine. The king of the said Iland of Java hath a brave and
sumptuous pallace, the most loftily built, that euer I saw any, it
hath most high greeses3 and stayers to ascend up into the roomes
therein contained, one stayre being of silver, another of gold,
throughout the whole building. Also the lower roomes were paved all
ouer with one square plate of silver, another of gold. All the walls
upon the inner side were seeled ouer with plates of gold, wherupon
were ingraven ye
pictures of knights, having about their temples, ech
of them a wreath of golde, adorned with precious stones. The roofe
of the palace was of pure gold. With this King of Java the great Can
of Catay hath had many conflicts in war; whom notwithstanding the
said king hath always overcome and vanquished.
1: Perhaps he meaneth Cammori.
2: Sumatra.
3: Steps.

N
Of certaine trees yeelding meale, honey, and
poyson.
EERE unto the said Iland is another countrey called Panten, or
Tathalamasin.1 And the king of the same countrey hath many
Ilands under his dominion. In this land there are trees yeelding
meale, hony, wine the most deadly poison in all ye
whole world:
for against it there is but one only remedy: that is this: if any man
hath taken of ye
poyson, would be delivered from the danger
thereof, let him temper the dung of a man in water, so drinke a
good quantitie thereof, it expels the poyson immediatly, making it
to avoid at the fundament. Meale is produced out of the said trees
after this maner. They be mighty huge trees and when they are cut
with an axe by the ground, there issueth out of the stock a certain
licour like unto gumme, which they take and put into bags made of
leaues, laying them for 15 days together abroad in the sunne, at
the end of those 15 dayes, when the said licour is throughly
parched, it becometh meale. Then they steepe it first in sea water,
washing it afterward with fresh water, and so it is made very good
savorie paste, whereof they make either meat or bread, as they
thinke good. Of which bread I my selfe did eate, it is fayrer
without somewhat browne within. By this countrey is the sea
called Mare mortuum, which runneth continually Southward, into ye
which whosoever falleth in (is) never seene after. In this countrey
also are found canes of an incredible length, namely of 60 paces
high or more, they are as bigge as trees. Other canes there be
also called Cassan,2 which overspread the earth like grasse, out of
euery knot of them spring foorth certaine branches, which are
continued upon the ground almost for the space of a mile. In the
said canes there are found certaine stones, one of which stones,
whosoever carryeth about with him, cannot be wounded with any
yron: therefore the men of that countrey for the most part, carry

The complete guide to developer first application security By Github.Com

More Related Content

Similar to The complete guide to developer first application security By Github.Com

Recently uploaded

The complete guide to developer first application security By Github.Com