1 Security in SCM

1.1 Introduction

Security in the Software Configuration Management should aim to identify the misconfigurations or the items that make the systems vulnerable and track any unusual changes or "bad" changes to critical data. Organizations can quickly identify a breach if there are some standard configurations setup such as corporate hardening standards for their systems which can continuously monitor for indicators of compromise or create some baselines to identify changes to these standards.

Security aspects in SCM should provide with a complete set of security functionality including:

Authentication and Authorization: To ensure only authorized members and perform specific changes in the whole development process. The system should be able to safely authenticate its users. Not only this, what kind of authentication mechanisms are used, that is of essential importance too. If the system uses tokens like passwords, proper passwords protection mechanisms should be used over a network such that it is not easily readable to accessible to anyone else other than the intended owner of it.

Confidentiality and Integrity: The system should maintain the confidentiality of the data it stores such that only authorized members should be able to read/write/update information based on the permissions provided to them thus aiding towards unintentional or malicious repository corruption.

Access control: To ensure threats related to confidentiality of the project development is measured from time to time as the project grows and is properly handled. The system should be designed in such a form that the privacy of a data is appropriately handled, i.e., it should not be possible to easily retrieve data that users want to protect, such that either such data should not be stored, or if required to store, should be stored in such a way that it does not spread.

Availability and Trust: Security in SCM should ensure how well is the system available to those who need it, and how protected is it to malicious attacks. Not only availability, the system should make sure that its communication with its authorized users is secured on a trusted path.

Accountability: By recording any action in the SCM process. Any unauthorized action to be highlighted along with the frequency of its occurrence, and root cause analysis to be done on any security threat followed with a plan for required action.

Audit and Accuracy: Audit mechanisms to be followed by monitoring any changes between different versions of objects, observing the history of any configuration item and ensuring that any change process is documented and accurate as per the defined policies.

Self-protection and recovery mechanisms: The system should be able to protect itself and if faced with any malicious attacks it should be able to fix and recover itself or be able to shutdown/pause immediately by notifying the concerned as early as possible so that appropriate action can be taken. The timestamps, change sets, history of data or logs of the system should be trustable and reliable.

Record history: Security in SCM should not only protect the "current" versions of the software but also its previous versions so that if any previous versions is needed it can recall that version correctly. Any changes made to the software should be recorded, even the "undoing" of any changes should be recorded. If very old history logs need to be archived, proper archiving and protection mechanisms should be designed and used.

1.2 Authorization & Authentication

The Authentication and Authorization functionality should be Role driven in SCM whereby following roles can be defined.

Developer: A Developer (or user having "Developer" role) is responsible for the development of modules (single/multiple), features, or any enhancements of the software project code. A developer can perform tests in his/her local environment which may be known as "Dev" environment.

Reviewer: A Reviewer is responsible for reviewing the code of several Developers before it can be integrated or merged with other modules of the software project, or before it is approved for next level of testing or development.

Integrator/ Integration Manager: An Integrator approves and merges several modules of the software product checked in by the developers and performs builds to ensure sanctity of the merged code. He or she is responsible for integration testing as well.

Build Manager: A Build Manager is responsible for performing builds, managing the built versions and overlooking the completion of the allocated model/project/module or function; for rebuilding any released product versions and to notify the integrator or developers if any issue found in any of the built products through any defect management system.

SQA Manager: The SQA Manager tests the quality of the product by performing some final quality tests of the developed product. These tests can be functional tests or User Acceptance tests, Operational tests, etc. SQA Manager may then mark the product version to be released.

System Administrator: A System Administrator is responsible for the overall administration of the SCM system including administration of any resources of SCM, archiving of any built product versions, security aspects in SCM, and establishing backup policies and maintaining backups of resources.

This functionality can be integrated with ADFS (Active Directory Federation Services) to control user access. ADFS a software component developed by Microsoft which can operate on Windows OS. It is used to provide end users with a single sign-on access (SSO) to various applications or systems located across corporate boundaries, outside the organization's firewall. ADFS is built upon Microsoft's traditional Active Directory technology which is used to store usernames and passwords of an organization and uses this data to manage and secure access to workstations and servers on a Windows domain. ADFS helps reduce the complexity around password management and guest account provisioning by providing the SSO facility.

1.3 Security with Version Control Tools

A Repository is like the central database containing the complete history of all files in the project and shared by all members of a project. It is structured much like a file system containing a hierarchy of nested directories and files. Repositories should be set up on the local disk of the server and access to the server is very well secured. To establish security, one should never attempt to share a repository between computers by placing it in a shared location on the network. Instead, the SCM tools should setup the security mechanism using suitable protocols for authentication and safety of the repositories.

Various version control tools have clients who generally access a repository by communicating with a server. The format of this communication is termed the protocol. Protocols like HTTP and HTTPS are best suited to access repositories available via public networks such as the Internet. Some servers might provide access via multiple protocols, e.g. projects providing HTTP for anonymous and read-only access and HTTPS for write access which may be limited to defined roles. The version control tools can be setup on a webserver like Apache web server using http/https protocols or on web-host tools offering the secure protocols like GitHub/Bitbucket etc.

1.4 Security Types

SSH (Secure Shell): SSH encrypts all data that it sends between clients and servers and allows you to authenticate with either a username and password, or by using certificate-based authentication. It has become the de facto standard when communicating with UNIX/Linux servers and network devices, such as routers and switches.

TLS (Transport Layer Security): TLS is the standard method of encrypting client/server data that starts with a key exchange, authentication, and the implementation of standard ciphers. Many IP-based protocols, such as HTTP (HTTPS), Simple Mail Transfer Protocol (SMTP), Post Office Protocol version 3 (POP3), File Transfer Protocol (FTP), and Network News Transfer Protocol (NNTP), support TLS to encrypt data.

LDAP: The version control tools can be integrated with LDAP (Lightweight Directory Access Protocol) which allows to query items in any directory service that supports it, like Active Directory service (AD). It can provide all sorts of functionality like authentication, group and user management, policy administration and more. LDAP is a protocol for administering the data of a directory service.

Web-hosting Tools: Apart from integrating the version control tools with 3rd party tools, there are also some hosting tools which provide authentication mechanisms embedded into it. Depending on the SCM architecture, organizations can make used of such web-hosting tools as well.

2. Distributed Version Control System (DVCS)

A Distributed Version Control System is a form of version control where there is no single central version of the codebase, but rather the codebase is mirrored at multiple sites or on every developer's machine. Following diagram is an illustration of a Distributed Version Control System for an enterprise team which is a multi-site project. Each location has its own set of repositories which developers can read/write and check-in their code, and when required to combine the project with other's development, they can push/pull between sites.

A Distributed Version Control System at Scale is depicted in the below diagram. Following are its features:

• Extremely faster pushing and pulling of change sets as the tool only needs to access the hard drive, not a remote server.
• Commit new change sets locally and then, once the group of change sets are ready push all of them at once.
• Pushing and pulling without an internet connection.
• Isolated development.
• Individual developer has a full copy of the project repository, changes can be shared with one or two other team members at a time for peer review.
• Integrated with DevOps CI/CD platform.

2.1 Challenges of Distributed Development

Distributed Development is best suited for modular projects or Model Driven Development (MDD) where different teams can work on specific modules in an independent manner thereby providing interoperability, re usability and maintainability, through different languages and platforms, which in turn helps improve software quality and developers’ productivity.

However, there can be some challenges in Distributed Development which can be addressed.

• May fail at intercommunication: Communication is the key requirement s distributed projects as it must be open to all involved and not just be limited to one single location. If the multiples teams across different locations may fail at intercommunication, it may lead to delay developmental processes and affect timelines.
• Requires high management: Distributed development is one of the highest forms of collaboration and thus it requires high management capabilities, a highly efficient infrastructure and a well-defined organization chart with measures to ensure compliance without which Distributed projects may fail.
• Few programming practices fail: Few programming practices like ‘Pair programming’ tend to fail in distributed development if peers are based at different locations.
• Concern for Security: Security is a concern when dealing with distributed development. Higher security measures are required in such projects.
• Productivity may decrease: Studies have resulted that all employees working in the same office are able to coordinate their work better and are more productive. A distributed environment needs to ensure frequent interaction not only for good coordination but also to ensure that the development is on right track else the results may deviate.

3 SCM for Cross-Platform Developments

Cross-platform development is the practice of developing software applications or products which can be operated on multiple platforms or environments so that such applications are independent of platforms and can work well in any habitat. Different strategies are used to accomplish such cross-platform software developments. For e.g., there may be compilation of different versions of the same program for different operating systems, or they may be platform specific files stored to be used for their respective operating systems, or developers can make use of modern application programming interfaces (APIs) to adjust a piece of software to a specific platform.

Cross-platform version control Tools:

There are several Version Control tools that support various platforms and work well to store source code of complicated cross-platform software projects, except for a few ones like Microsoft Visual SourceSafe (VSS) which is a Windows only tool.

Listed below are few popular cross-platform version control tools having different types of Repository Models. The types of platforms supported by different tools are listed alongside. Information have been gathered from source: https://en.wikipedia.org/wiki/Comparison_of_version_control_software

4. SCM for Containers and Microservices

Microservices refers to microservice architecture which uses suites of independent services to develop any software, mobile or web applications. These services are created to server only one specific business function which are independent of each other and does not necessarily have to be written in the same programming languages or use the same data storage. The microservices use lightweight HTTP, REST or Thrift APIs for communicating between themselves. Microservices are independently deployable and thus can offer more flexibility in various dimensions.

Since Microservices are independent of each other and may use different platforms, containers work best with microservices as they provide the flexibility to use different platforms by making applications very light weight and easily scalable.

Shown below is a software architecture style, in which complex applications are composed of small, independent processes communicating with each other using language-agnostic APIs. These services are small, highly decoupled and focus on doing a small task.

Following points denotes the architecture:

• Granular, Decentralized, Disposable, Evolutionary Design
• Fine grained, Distributed
• Cloud native, API First
• Principles – Evolutionary Design, Resilience, Automation – Everything as Code
• Config files, code of microservice are version controlled in SCM tools like GIT
• Docker, docker files and any other template files like compose YML or Kubernetes deployment files can be versioned controlled in SCM tools like GIT

Sunil Khatri

Add comment