Department of Collegiate and Technical Education Diploma in CS&E

Course: Cyber Security Code: 20CS54I

WEEK-12: Session-4
 Pre-Commit Security Controls
 Rapid Risk Assessment
 Git Hook Security
 Code Editor Extensions
 Branch Protections
 CodeOwners
 Commit Security Controls
 Static Analysis Security Testing
 Component Analysis

Pre-Commit Security Controls:

 The purpose of these pre-commit Git hooks is to check file types and content against pre-defined
rules in order to identify potentially sensitive information prior to commit.
 Managing sensitive content before it is committed to GitHub helps maintain our overall security
posture, and also helps prevent the Leak Detection Service (LDS) triggering an alert, thus reducing
the potential for secrets requiring manual removal from Git histories and for keys which would
then require cycling.
Rapid Risk Assessment:
 A typical Rapid Risk Analysis/Assessment (RRA) takes about 30 minutes. It is not a security
review, a full threat-model, a vulnerability assessment, or an audit. These types of activities may
however follow an RRA if deemed appropriate or necessary.
 The main objective of the RRA is to understand the value and impact of a service to the reputation,
finances, productivity of the project or business. It is based on the data processed, stored or simply
accessible by services.
 Note that the RRA does not focus on enumerating and analyzing security controls. The RRA
process is intended for analyzing and assessing services, not processes or individual controls.
 Data is the most important item in risk management. Software, websites, infrastructure, networks
and people handle, process, exchange and store data.
 The RRA focuses on creating a summary of the risks associated with your data. Key points:
 Quick! -The RRA takes 30 to 60 minutes maximum.
 Very high-level- Details are for complete threat models. The RRA can become a complete
threat model over time though!
 Concise, readable- Short and with clear risk levels.
 Easy to update- Can be run during any phase of the project development and continuously
updated.
 Informative- Collects risk impact and a data dictionary. Also collections information about
how the service functions.

[Cyber Security-20CS54I] Page 1

Department of Collegiate and Technical Education Diploma in CS&E
 Let you know what to do- The RRA includes the list of recommendations from the security
team with a priority for each item.
 This helps to make the following type of risk-based decisions:
 Is the security provided by a given platform appropriate to host a specific classification of data?
 How much should we care about maintenance, etc?
 Is there anything obvious we should really look at fixing right now?
 Where should we focus our efforts to significantly increase the security or the service?
 Did we forgot anything, or had any blind spot we hadn’t thought of?
Git Hook Security:
 Hooks are scripts that run at different steps during the commit process. They are completely
customizable and will trigger events at key points during the development life cycle. Some
examples of hooks are:
 Rejecting/accepting commit messages based on formatting
 Notifying key personnel when high-risk code changes
 Starting the build process to update the development environment
 Triggering a scan of the code or application
 Commit hooks are categorized into two buckets: Client-Side Hooks and Server-Side Hooks.
Client-Side hooks reside on the developer’s local machine, while server-side hooks reside on a
central server. Within each hook category, a hook can be called before, during, or after a commit.

Client-Side Hooks:
Pre-Commit
 The pre-commit hook runs on the git commit command before Git checks for a commit message or
generates a commit object. This hook can be used to run any tests on the snapshot that is about to
be committed
Examples:
 Search for secrets left in the code
 Abort a commit if a high-risk file or folder has been changed
 Run a linter to ensure code is following coding standards
Prepare-Commit-Msg
 The prepare-commit-msg hook runs just after the pre-commit hook (assuming that the commit has
not aborted) to populate the commit message with text. This hook can be used as a template to
prepare the commit message that gets printed with the commit. It will save time by automatically
formatting and pulling certain commit information, like the branch name, issue, or developer
name.
Examples:
 Populate a list of false positive results from a scan run during the pre-commit hook
 Generate a message with the associated issue from your issue tracker
 Generate a message template for different types of commits: message (-m or -F
option), merge (if the commit is a merge), template (-t option), squash (if a commit squashes
commits)
Commit:
 The commit-msg hook runs after the prepare-commit-msg hook and after the user completes the
commit message. Where the prepare-commit-msg hook prepares the template for the message,

[Cyber Security-20CS54I] Page 2

Department of Collegiate and Technical Education Diploma in CS&E
this commit-msg hook checks that the message has been properly formatted. The user could have
changed the commit message from the prepare-commit-msg hook. This hook can verify and warn
the user of the message error or can abort the commit entirely.
Examples:
 Checking that the false positives were not removed from the prepare-commit-msg hook
 Checking that the message is not blank and contains the issue number
Post-Commit
 The post-commit hook runs immediately after the commit-msg hook successfully runs. This hook
will not change the status of the overall commit. Instead, this hook is used to notify any necessary
people or processes.
Examples:
 Send a slack notification to inform that high-risk code has changed
 Send an email to the team lead to start code review
Pre-Rebase
 The pre-rebase hook runs before the rebase takes place. This hook can be used to check that the
rebase will not break the git history since a rebase could be dangerous. Usually, the logic in this
script is a bit more complex than other scripts. You can view a default pre-rebase hook with the
sample script by typing: cat .git/hooks/pre-rebase.sample.
Examples:
 Completely disallow rebasing
 Allow rebasing only if topic branch has not merged into the next mainline branch
Post-Checkout
 The post-checkout hook runs after a successful call from git checkout. This hook can be used to set
up the development environment after switching branches.
Examples:
 Installing dependencies that are in the checked out branch that are not required in other
branches
 Removing any unnecessary files that have been ignored during the git checkout process
 Update any hook scripts that have been altered

Server-Side Hooks:
Pre-Receive
 The pre-receive hook runs anytime a client pushes a commit using git push.
Examples:
 Reject a push if secrets are committed in the code
 Reject a push if a user has committed to a disallowed folder
 Reject a push if the commit has bypassed a code review
Post-Receive
 The post-receive hook runs after a push commit runs successfully. This hook is used to send
notifications on a successful git push. This hook is similar to the client-side hook post-commit but
would be a more logical place to perform notifications as this hook resides on a central server.
Examples:
 Send an email notification to the engineering team
 Trigger a call to the server that can run a SAST/DAST scan

[Cyber Security-20CS54I] Page 3

Department of Collegiate and Technical Education Diploma in CS&E
Code Editor Extensions:
 Extensions are add-ons which you can use to customize and extend your experience with Azure
DevOps. They're written with standard technologies - HTML, JavaScript, CSS - and developed
using your preferred development tools.
 Extensions get published at the Visual Studio Marketplace, where they can be kept private for you
and your team or shared publicly with the millions of developers currently using Azure DevOps.
 We also need extensions that will help us with auto code generation, problems, indentation fixing
and also provide recommendations while we implement.
 Examples:
 vscode-icons - Visual Studio Marketplace. ...
 Git Graph - Visual Studio Marketplace. ...
 YAML - Visual Studio Marketplace. ...
 Ansible - Visual Studio Marketplace. ...
 Azure Terraform - Visual Studio Marketplace. ...
 Bicep - Visual Studio Marketplace. ...
 Azure Pipelines - Visual Studio Marketplace.
CodeOwners :
 Code Owners define who develops and maintains a feature, and own the resulting files or
directories in a repository.
 The users you define as Code Owners are displayed in the UI when you browse directories.
 You can set your merge requests so they must be approved by Code Owners before merge.
 You can protect a branch and allow only Code Owners to approve changes to the branch.
 Use Code Owners and approvers together with approval rules to build a flexible approval
workflow:
 Use Code Owners to define the users who have domain expertise for specific paths in your
repository.
 Use Approvers and Approval rules to define domains of expertise (such as a security team) that
are not scoped to specific file paths in your repository.
o Approvers define the users.
o Approval rules define when these users can approve work, and whether or not their
approval is required.

[Cyber Security-20CS54I] Page 4

Department of Collegiate and Technical Education Diploma in CS&E

Set up Code Owners

Create a CODEOWNERS file to specify users or shared groups that are responsible for specific files and
directories in a repository. Each repository can have a single CODEOWNERS file. To create it:
1. Choose the location where you want to specify Code Owners:
 In the root directory of the repository
 In the .gitlab/ directory
 In the docs/ directory
2. In that location, create a file named CODEOWNERS.
3. In the file, enter text that follows one of these patterns:

 The Code Owners are now displayed in the UI. They apply to the current branch only.

[Cyber Security-20CS54I] Page 5

Department of Collegiate and Technical Education Diploma in CS&E
Commit Security Controls:
Secure Github And Protect Your Source Code
Github authentication & access
 Standard login to Github is via basic credentials, a username and password. But we recommend
requiring more secure authentication flows since the username is public, which means once
attackers locate the password for an account (using social engineering, data from prior breaches,
or other nefarious means) they can easily login and gain user access to the SCM.
2-factor authentication
 If you haven’t already, the most basic practice to implement is to require that all teams,
employees, and contractors set up 2FA in Github:
SSO (GitHub enterprise only)
 SAML authentication for your organization through an identity provider is available for GitHub
Enterprise users. if you have the option, implement it.
Limit access to specific IP addresses
 You can restrict access to your organization’s assets by configuring a list of IP addresses that are
allowed to connect by setting the “IP allow list” configuration.
Repository Access
 Base permissions
 These are the base permissions every member of the organization receives. The most secure
option here is to set it to none. This will require permissions for repositories to be set explicitly for
each repository based on user or teams.
 Outside collaborators
 Outside collaborators are users with access to a private repository that are not part of the
organization. We strongly recommend that outside collaborators are tightly controlled, with as
minimal access as possible. They should be monitored at all times.
 View current access permissions
 Github recently added a feature that allows users to inspect access on a per repository basis.
 In the repository settings navigate to: ‘Settings -> Manage Access’ to see an overview of the
access permissions to that repository:
Leak Prevention
 Disable forking (org + repo)
 Forking is the act of creating a copy of a specific repository. Forking is meant to allow developers
to create a copy where they can experiment on the code without affecting the original repository .
 From a security perspective, there are two main issues with forking. The first is that the more
forks there are for a repository it is harder to keep track of the security of each fork, and the
problem of securing the repository grows exponentially the more forks a repository has. The
second is that forking can easily be used to create a copy of a repository in a user’s private
account. Very dangerous.
There are two types of forking:
1. Organization forking settings. This is a cross organization settings that will apply to all
repositories.
2. Per repository settings.

[Cyber Security-20CS54I] Page 6

Department of Collegiate and Technical Education Diploma in CS&E
 Disable visibility changes
 This will prevent developers from changing the visibility from private to public repositories.
 Disable public repositories
 If you have no need for public repositories, or have an organization that is entirely dedicated to
proprietary code, then you can disable public repositories across the organization.
Tampering Protection
 Enable branch protection rules
 Github comes with built-in controls meant to enforce tempering protection through workflow
definitions. The most basic of them is requiring code review before merging code to the
production branch.
 This makes sure that a developer cannot push code that hasn’t been reviewed by another
developer to the production environment. These settings can be found under each repository’s
configurations.
 As you can see, you can control the number of reviewers needed to approve a commit. You
can also require that the code owners themselves approve commits.
 Another setting important to know in this context: Require signed commits. This means every
commit is signed by a developer and can be attributed back to someone aka totally and easily
traceable.
Source Code Security
 Enable dependency checks
 Github comes with built-in support for dependency vulnerability checks after acquiring
dependabot. However, this setting needs to be turned on on a per-repository basis.
 Once a dependency vulnerability has been identified, an alert will be created and if possible an
automated pull request will be created to mitigate the issue. Under the security alerts section in the
repository settings, you can define who will be notified when a security issue is identified.
 Review Your Audit Log
 Under the organization’s settings, you can access the audit log and view various events that
happened in Github. Periodically review the audit log and make sure that there are no anomalous
or suspicious activities.
 Inspect Third Party Access and Github Applications
 Github allows you to grant access to third party applications. On the organization settings review
both the “Third-party access” and “Installed Github Apps” to make sure no unauthorized access is
granted.
Static Analysis Security Testing:
Static Application Security Testing (SAST) :

White-box testing
 SAST is a form of white-box security testing which has full access to the underlying source code
and binary. It will test your program via an inside-out approach. Specialized SAST software such
as GitLab, Klockwork or AppThreat will scan your source code automatically either during the
coding process, or after you have committed the code to your pipeline.
 For example, for Klockwork’s users, once you have established a link between your project and
Klockwork Desktop, it allows you to code your program normally using any IDE of your choice as
long as it is open in the background. Each time you save the file, Klockwork Destop will update the
[Cyber Security-20CS54I] Page 7
Department of Collegiate and Technical Education Diploma in CS&E
code automatically and perform a scan on the spot. If it detects any security issues, it will display
them on the user interface.

Early Detection
 SAST is typically conducted at the early stage of the system development life cycle, usually during
or after the development stage. This allows you to identify any form of security vulnerabilities
before going into the testing or quality assurance phase.
 It is a lot easier to fix problems when they are discovered early. Besides, most SAST executions
will flag lines of code with the vulnerabilities. This can be extremely useful and serve as pointers to
developers when fixing vulnerabilities. It also costs less to maintain and develop the project.

False Positives
 SAST methodology is prone to high number of false positives compared to DAST. As a result, a
situation might arise where developers have wasted valuable time and resources fixing imaginary
problems in their system. Such a downfall can be costly in the long term if there are hundreds or
thousands of false positives.

Language-Dependent
 SAST is language-dependent in terms of analyzing the underlying source code and binary. Most
SAST tools specialize only in a few computer languages. You will not be able to find a one-size-
fits-all SAST tool for every programming language used in your projects. As a result, scaling and
maintaining a project build with different computer languages will be an enormous task.

Does not cover run-time vulnerabilities

 SAST is not capable of detecting any form of run-time vulnerabilities as it only scans the static
code and binary. If you have incorrectly configured your system, a SAST tool will not be able to
identify run-time issues leading to a false sense of security among the developers.

[Cyber Security-20CS54I] Page 8

Department of Collegiate and Technical Education Diploma in CS&E
Component Analysis:
 Component Analysis is the process of identifying potential areas of risk from the use of third-party
and open-source software and hardware components. Component Analysis is a function within an
overall Cyber Supply Chain Risk Management (C-SCRM) framework. A software-only subset of
Component Analysis with limited scope is commonly referred to as Software Composition
Analysis (SCA).
 Any component that has the potential to adversely impact cyber supply-chain risk is a candidate
for Component Analysis.

Common Risk Factors

Component Inventory

 Having an accurate inventory of all third-party and open source components is pivotal for risk
identification. Without such knowledge, other factors of Component Analysis become impractical
to determine with high confidence. Use of dependency management solutions and/or Software Bill
of Materials (SBOM) can aid in inventory creation.

Component Age

 Components may have varying degrees of age acceptance criteria. Factors that impact acceptable
age include the type of component, the ecosystem the component is a part of (Maven, NPM, etc),
and the purpose of the component. The age of a component may signify use of outdated
technology and may have a higher probability of being passed over by security researchers.

Outdated Components

 Newer versions of components may improve quality or performance. These improvements can be
inherited by the applications that have a dependency on them. Components that are end-of-life
(EOL) or end-of-support (EOS) also impact risk. Two common approaches to community
supported open-source is:

 Support the latest revision of the last (x) releases - (i.e. 4.3.6 and 4.2.9)
 Support only the latest published version (i.e. 4.3.6 today and 4.4.0 tomorrow)

 Depending on the risk appetite, it may be strategic to only use third-party and open source
components that are supported.

Known Vulnerabilities

 Historically, known vulnerabilities referred to entries (CVEs) in the National Vulnerability

Database (NVD). The NVD describes (via CPE) three types of components:

 Applications (includes libraries and frameworks)

 Operating Systems
 Hardware

[Cyber Security-20CS54I] Page 9