[Part 1] DevSecOps Analytics

Welcome to the 1th DevSecOps article (previous article: https://medium.com/@lahutsin/part-0-devsecops-introduction-412e3aa019a6) (0–7 — spoiler). Today we will talk about analytics processes, and what types are used in DevSecOps and we will talk a little about each of them. We will also touch on the topic of vulnerabilities in more detail. I would like to thank you in advance for reading and your comments. I hope you will be satisfied with getting some knowledge in this specialization, and continue to develop this area in the future. This series of articles assumes a basic understanding and knowledge of DevOps. As an author, I do not claim to have a final or conclusive expert opinion in this area.

DevSecOps Analytics

DevSecOps Analytics is a data-driven approach to improving security in the DevOps software development lifecycle. It uses machine learning and artificial intelligence to analyze large amounts of data to identify vulnerabilities and security threats.

To successfully implement DevSecOps Analytics, it is important to ensure that all members of the DevOps team understand how to use the data collected in the analysis process and have access to the appropriate tools for monitoring and analyzing application security.

All data collected and structured should be anonymized and not tied to any specific customer or organization. This is done to collect and store data cases without compromising sensitive information, and to build a knowledge base.

DevSecOps Analytics uses data and machine learning to improve security in the software development lifecycle. It is important to ensure that all team members understand how to use the data and have access to the right tools.

Vulnerability Analysis:

CVE

Common Vulnerabilities and Exposures (CVE) is a standard system for identifying and tracking vulnerabilities in computer security. CVE identifiers are assigned to vulnerabilities and exposures to provide a single way to share information about them.

Static code scanning (SonarQube) can be used to detect vulnerabilities during the build and delivery of software, including CVEs. These vulnerabilities can then be evaluated and prioritized for remediation

CVE helps to improve software security by quickly disseminating information about new vulnerabilities. Static code scanning can be used to detect vulnerabilities.

CWE

CWE (Common Weakness Enumeration) is a list of software and hardware vulnerability types. It helps software developers and security professionals understand and classify vulnerabilities, allowing them to more effectively analyze and remediate security issues in their software code.

CWE is part of the Software Assurance initiative, developed jointly by the MITRE Corporation and an international community of security experts. It provides a structured catalog of vulnerabilities and associated patterns.

CWE is a list of software and hardware vulnerability types that helps developers and security professionals write more secure software.

CPE

CPE (Common Platform Enumeration) Software refers to software that is identified and classified using the Common Platform Enumeration (CPE) format. CPE is a standard developed by the MITRE Corporation and is used to uniquely identify products and operating systems.

An example of a CPE identifier for software can look like the following:

cpe:/o:microsoft:windows

(where “o” denotes the operating system, “Microsoft” is the manufacturer, “Windows” is the product)

CPE Software is important for identifying and classifying software in a variety of contexts, such as vulnerabilities, configuration management, and so on. It helps to standardize and facilitate the processing of software information, which is important for many aspects of information security and IT infrastructure management.

References (context CVE)

CVE references are links to various resources related to a vulnerability, such as articles, patches, exploits, and other vulnerability databases.

Here is a summary of the different types of CVE references:

• Links to articles or documentation
• Links to patches and updates
• Links to vulnerabilities in other databases
• Links to exploits or Proof of Concept (PoC)

CVE references can be used by software developers, security professionals, and other stakeholders to understand and address the issues associated with a specific vulnerability.

CVSS Scope

CVSS Scope is a component of the Common Vulnerability Scoring System (CVSS) that defines the context and impact of a vulnerability on the target system. It includes three aspects: user interaction, attack complexity, and privileges required.

CVSS Scope helps to assess the context of a vulnerability and take into account various factors that may affect the actual threat and impact of the vulnerability on the system.

CVSS Scope is a metric that helps assess the context and impact of a vulnerability on the target system. It includes three aspects: user interaction, attack complexity, and privileges required.

Against

Against is a preposition that indicates the direction or target against which something is compared or opposed. In the context of information security or cybersecurity, “against” is used to describe protection or mitigation of threats, attacks, or vulnerabilities.

For example:

• Protection against cyber attacks
• Fighting against viruses
• Protecting data against unauthorized access

In these contexts, “against” indicates that a subject (system, data, organization) takes measures or has protective mechanisms to prevent, mitigate, or limit threats or risks.

Exploit DB

Exploit DB is a popular database of vulnerabilities, exploits, and vulnerabilities found in various software products. It can be used in DevSecOps to:

• Integrate with vulnerability analysis tools to automatically check software code or infrastructure for known vulnerabilities.
• Keep the database updated with new vulnerabilities as they become available.
• Link vulnerabilities to corresponding tasks or bugs in the bug-tracking system.
• Analyze vulnerabilities to understand typical security issues associated with specific software products or libraries.

<!> It is important to use Exploit DB in compliance with laws and ethical standards. The database contains information about real vulnerabilities, and its use should be directed at improving security and protecting systems. <!>

Exploit DB is a useful tool for integrating security into the development and delivery process of software.

Basic principles of CI/CD pipeline analysis

The principles of CI/CD pipeline analysis in DevSecOps include the following stages:

• Security requirements analysis at the planning stage: Identify the security requirements that must be considered at all stages of the CI/CD process. Determine which vulnerabilities can be detected during development, testing, and deployment.
• Code and configuration analysis at the development stage: Use static code analysis tools (SAST) to detect vulnerabilities in the code before it is compiled and executed.
• Vulnerability analysis at the testing stage: Use dynamic security analysis tools (DAST) to detect vulnerabilities in the application while it is running.
• Security analysis at the deployment stage: Use tools such as WAF (Web Application Firewall) to help detect and block attacks on the application.
• Real-time security monitoring: Use security monitoring tools such as IDS (Intrusion Detection System) and IPS (Intrusion Prevention System) to detect and prevent attacks on the application.

CI/CD processes must be in a closed loop, meaning that the integrity of the assembly, formation, and delivery of software to the endpoint must be checked throughout the process. This is what security requirements analysis is for.

CI/CD pipeline analysis in DevSecOps involves analyzing the code, configuration, vulnerabilities, and security of the application at all stages of the CI/CD pipeline. This helps to identify and mitigate security risks early on.

Basic principles of analyzing application architectural solutions in the Cloud

When developing and analyzing architectural solutions for applications in the Cloud, it is necessary to consider the following basic security principles:

• Identity and authentication: The application must have mechanisms for identifying and authenticating users and administrators. This ensures protection against unauthorized access to the application.
• Data encryption: The application must use data encryption to protect the confidentiality of information transmitted between users and the application. Encryption can be implemented using SSL certificates and other methods.
• DDoS protection: The application must have mechanisms for protecting against DDoS attacks.
• Security monitoring: The application must have security monitoring mechanisms. This allows you to detect and prevent attacks on the application in real-time.
• Secure data storage: The application must have mechanisms for secure data storage. This can be implemented using data encryption and other methods.
• Secure storage of backup copies of data: The application must have mechanisms for secure storage of data copies. This applies to both sensitive and de-identified information.
• Software patching management: The application must be regularly updated and managed to ensure security. This can be implemented using automated tools such as Ansible and others.

DevSecOps helps to ensure the security of Cloud applications at all stages of their life cycle. It is important to consider the basic security principles and use automated tools for monitoring and updating software.

When developing and analyzing Cloud application architectures, consider the following security principles: identity and authentication, data encryption, DDoS protection, security monitoring, secure data storage, secure backup storage, and software patching management. Use DevSecOps to ensure security at all stages of the application lifecycle.

When making an architectural decision for a Cloud application, consider the following:

Customer, developer, and security engineer requirements. Don’t ignore any requirements, as this can lead to problems in the future.

Cloud infrastructure provider recommendations. Review and consider these recommendations.

Basic security principles. This includes using a system for logging actions in repositories, universal SSL services, proper storage of critical data, secrets, backups, and strict access control rules.

Patching of software in legacy areas. This is essential for the security of the entire infrastructure, especially for software and legacy services configured using orchestration tools as code.

Consider customer, developer, and security engineer requirements, cloud infrastructure provider recommendations, basic security principles, and patching of software in legacy areas when making architectural decisions for Cloud applications.

Additional note:

It is important to note that security is not just about using the right tools and technologies. It is also about people and processes. Security should be considered at every stage of the software development lifecycle, from requirements gathering to deployment and maintenance.

Extra:

CVE DB List:

• https://cve.mitre.org/
• https://nvd.nist.gov/
• https://www.cvedetails.com/
• https://www.exploit-db.com/
• https://www.rapid7.com/db/
• and more…

Analytic tools for CI/CD in DevSecOps:

• SonarQube
• OWASP Dependency-Check
• Clair
• GitLab: Container Scanning
• GitLab: The DevSecOps Platform
• Semgrep
• Bandit
• Dagda
• and more…

Analytic tools for Clouds in DevSecOps:

• AWS Security Hub
• Azure Security Center
• Dome9 Security
• Scout Suite
• Lynis.io
• Security Monkey
• CloudTrail
• OpenSCAP
• and more…

Write your opinions in the comments.
What do you think about this?

Best Regards,
Alex Lahutsin