Jenkins is an open-source automation server used to automate software building, testing, and deployment through Continuous Integration and Continuous Delivery (CI/CD) pipelines. A Jenkins pipeline defines a sequence of operations, such as checking out source code, installing dependencies, executing build commands, running security tests, and preparing application artifacts.
The Jenkinsfile defines the pipeline configuration and its build stages. If an attacker modifies a Jenkinsfile or introduces an unauthorized command into a build stage, the pipeline may execute suspicious operations within the permissions and environment available to the Jenkins agent.
Malicious build-step injection may involve unexpected shell commands, unauthorized script downloads, suspicious command chaining, or attempts to access sensitive files and environment variables. Such behaviour can compromise build integrity, expose credentials, or affect the security of generated software artifacts.
In this use case, Jenkins is deployed on an Ubuntu virtual machine in an isolated VirtualBox laboratory. Controlled pipeline configurations are maintained in a Git repository, and harmless normal and suspicious build-step examples are prepared for testing. A publicly available cybersecurity dataset containing relevant command or script-behaviour records is also used for model development and evaluation. The selected dataset must provide features that can be mapped meaningfully to the behavioural features extracted from Jenkins build steps.
Python is used to process the public dataset, extract relevant features, and prepare structured data for analysis. The Local Outlier Factor (LOF) algorithm analyses the local density of feature vectors and identifies build steps that differ significantly from their surrounding behavioural patterns. Dataset preprocessing and feature compatibility checks are performed before the model is applied to Jenkins pipeline data.
The public dataset supports model development and evaluation, while controlled Jenkins pipeline test cases are used to assess the detection workflow in the target environment. Dataset records are not assumed to represent Jenkins-specific attacks automatically; only relevant records and compatible features are used. The limitations of applying dataset-derived patterns to Jenkins build steps are documented.
The proposed system does not assume that every unusual command is malicious. LOF generates anomaly scores, and the detected build steps are reviewed against security rules and the expected pipeline configuration before a security decision is made.
Semgrep CE provides supplementary static analysis for supported source code and security patterns. Gitleaks checks the repository for potential hardcoded secrets, while Trivy examines supported container images and configuration files for known vulnerabilities and security misconfigurations. These tools complement the primary AI-based detection mechanism rather than replacing it.
Docker is used where required to isolate controlled build execution. A Python-based Streamlit dashboard presents detected anomalies, affected pipeline stages, relevant indicators, security findings, and assessment results.
When a suspicious build step is confirmed, Jenkins pipeline controls are used to prevent the affected build from proceeding. The build configuration is reviewed, the unauthorized command is removed or corrected, and the pipeline is executed again to validate the remediation.
Application/Service: Jenkins CI/CD Pipeline
Jenkins is the target CI/CD automation service in this use case.
It executes pipeline stages defined in a Jenkinsfile and coordinates build, testing, and other automation tasks through configured agents.
Jenkins pipelines execute commands according to their configuration and the permissions available to the executing agent. If unauthorized or malicious commands are introduced into a build stage, they may execute as part of an otherwise legitimate pipeline.
Traditional pipeline execution does not automatically determine whether every command represents unusual or potentially malicious behaviour. Basic syntax validation and successful build completion cannot independently establish that a pipeline is secure.
Static analysis and secret scanning can identify certain security weaknesses, but they do not independently detect every malicious build-step behaviour. An additional behaviour-analysis mechanism is required to identify unusual patterns that warrant investigation.
Public cybersecurity datasets can provide records for developing and evaluating anomaly-detection techniques. However, the selected dataset must contain relevant behavioural information, and its features must be compatible with the features extracted from Jenkins build steps. Otherwise, its records cannot directly support reliable Jenkins-specific detection.
The proposed solution introduces public dataset collection, dataset preprocessing, compatible feature extraction, LOF-based anomaly detection, security-rule validation, risk prioritization, controlled build execution, and post-remediation validation.
Specific Attack: Malicious Build-Step Injection Attack
The controlled attack scenario evaluates whether an unauthorized or suspicious command introduced into a Jenkins pipeline can be identified before the affected build is allowed to proceed.
A controlled test Jenkinsfile contains normal build steps alongside harmless test cases representing suspicious command patterns. These may include unexpected external-download indicators, unusual command chaining, or attempts to reference sensitive environment variables.
The public cybersecurity dataset is used to support model development and evaluation. Controlled test cases are separately created in the laboratory to assess whether the resulting detection workflow identifies suspicious Jenkins build-step behaviour.
The laboratory uses inert test commands and dummy credentials. No real credentials are accessed, no malicious payload is executed, and no unauthorized external system is targeted.
AI-Based Anomaly Detection Combined with Secure CI/CD Pipeline Execution Controls
The primary security concept is AI-based anomaly detection combined with secure CI/CD pipeline execution controls.
A publicly available cybersecurity dataset is collected and inspected to identify records relevant to command or script behaviour. The selected records are preprocessed, and appropriate features are extracted and transformed into a structured representation. Dataset features are checked for compatibility with the features that can be extracted from Jenkins build steps.
The Local Outlier Factor algorithm analyses the local density of the prepared feature vectors and identifies samples that differ from their local neighbourhood. Since LOF is an unsupervised anomaly-detection algorithm, it does not require labelled classes for model fitting. Where suitable labels are available, they can support independent evaluation of the model's detection performance.
The model is evaluated using appropriate dataset samples and separate controlled Jenkins build-step test cases. Results from these two evaluation settings are reported separately so that performance on the public dataset is not incorrectly presented as proven performance against Jenkins-specific attacks.
The system extracts measurable features from pipeline commands and their associated metadata. Static security checks, repository comparisons, and predefined security rules provide additional evidence for validating alerts. An anomaly score alone is not treated as proof of malicious activity.
Gitleaks checks for potential hardcoded secrets, Semgrep CE identifies supported security patterns, and Trivy checks supported container images and configurations. These findings contribute to the overall security assessment but are not treated as proof that a build step is malicious.
A publicly available cybersecurity dataset containing relevant command or script-behaviour records is inspected before use. Only records and fields suitable for the intended analysis are selected.
Python is used to clean the selected dataset, handle missing or inconsistent values, remove duplicate records where appropriate, and prepare the data for feature extraction.
Relevant behavioural features are extracted from the dataset and Jenkins build steps. The feature representation is checked to ensure that the model receives compatible inputs during development, testing, and deployment.
The LOF model compares the local density of feature vectors and assigns anomaly scores to samples that differ from their local neighbourhood.
Pipeline configuration changes are reviewed against the approved Git version to identify unexpected modifications to build stages and commands.
Python parses supported pipeline scripts and extracts features such as command categories, shell operators, command-chain characteristics, external-download indicators, and references to environment variables.
Semgrep CE scans supported source code and security patterns using configured rules. Its ability to analyse individual Jenkins pipeline constructs depends on the language and rules supported by the selected version.
Gitleaks scans the project repository and relevant tracked files for potential hardcoded secrets.
Trivy scans supported container images, filesystems, and configuration files for known vulnerabilities and security misconfigurations.
Detected anomalies are checked against predefined security rules, approved command patterns, and the intended pipeline configuration.
Suspicious builds are prevented from proceeding until the required review or approval is completed.
Build agents are configured with only the permissions required for their assigned tasks, and sensitive credentials are not exposed unnecessarily to pipeline commands.
Controlled build jobs are executed in an appropriately isolated environment, using Docker where suitable and available.
Findings are prioritized according to the suspicious behaviour, available permissions, possible credential exposure, and potential impact on build integrity.
Confirmed unauthorized commands are removed or corrected, and the resulting pipeline configuration is reviewed before execution is permitted again.
The updated pipeline is analysed again, and controlled tests verify that the suspicious build step is no longer present and the expected build operations remain functional.
Jenkins is the primary platform because it executes the pipeline stages defined in the Jenkinsfile and supports controlled build validation.
A publicly available cybersecurity dataset is used as the data source for model development and evaluation. The selected dataset must contain relevant behavioural records, and its features must be suitable for mapping to the intended anomaly-detection workflow.
Pandas and NumPy are used to inspect, clean, transform, and prepare the selected dataset for feature analysis.
Python scikit-learn provides the Local Outlier Factor implementation used to analyse structured dataset and build-step features.
Python is used to parse supported pipeline scripts, extract measurable command characteristics, apply security checks, and coordinate the detection workflow.
Semgrep CE is an open-source static analysis tool used to identify supported security issues in source code and scripts.
Gitleaks is an open-source tool used to identify potential secrets exposed in source files and Git repositories.
Trivy is an open-source security scanner that supports container images, filesystems, and several configuration formats.
Nmap is an open-source network discovery and security auditing tool used for authorized assessment of the laboratory network.
Git maintains version history for pipeline configurations and allows the current Jenkinsfile to be compared with an approved version.
Docker provides container-based isolation for controlled build operations when compatible with the Jenkins agent configuration.
Streamlit provides a Python-based interface for displaying anomaly detection results and security assessment evidence.
Ubuntu provides the primary laboratory environment for Jenkins, Python, Git, and the associated analysis components.
Kali Linux provides a separate security-testing environment for controlled assessment activities where required.
VirtualBox provides the isolated virtual-machine infrastructure for the laboratory.
A Jenkins CI/CD pipeline is configured in an isolated Ubuntu laboratory, providing a controlled environment for evaluating malicious build-step detection.
A publicly available cybersecurity dataset containing relevant behavioural records is inspected and prepared for model development and evaluation. Dataset suitability and feature compatibility are assessed before its records are used by the anomaly-detection workflow.
The dataset preprocessing workflow uses Python, Pandas, and NumPy to clean and transform the selected records into structured feature data suitable for the intended analysis.
Feature engineering establishes a consistent representation for the relevant dataset records and Jenkins build-step samples. The compatibility checks help prevent unrelated or incompatible features from being incorrectly treated as equivalent inputs.
The Local Outlier Factor model analyses the prepared feature vectors and identifies unusual patterns based on local density. Its anomaly scores and predicted labels support further investigation rather than automatically confirming malicious activity.
Model performance is evaluated using appropriate dataset samples and, separately, controlled Jenkins build-step test cases. Where suitable test labels are available, evaluation metrics are calculated and the actual results are documented.
Detected anomalies are correlated with approved pipeline configurations and predefined security rules. Semgrep CE and Gitleaks provide supplementary static-analysis and secret-detection findings to support the security assessment.
Jenkins build execution controls are integrated with the security-validation workflow, allowing builds that fail required security checks to be stopped or held for review before proceeding.
The identified unauthorized build-step changes are corrected, and the updated Jenkinsfile is reviewed against the approved configuration to restore the intended pipeline behaviour.
Post-remediation testing verifies whether the suspicious build steps have been removed or corrected, while legitimate build operations are checked to ensure that the security controls do not unnecessarily disrupt the pipeline.
The complete Jenkins CI/CD build-step security workflow including public dataset preparation, feature engineering, LOF anomaly detection, cybersecurity scanning, security-rule validation, risk assessment, build execution control, remediation, dashboard reporting, and post-remediation evaluation is demonstrated in the controlled laboratory.
Research Breakthrough Possible @S-Logix