Is it possible to have environment variables on organization level for GitHub Actions? So something like organization secrets but just with environment variables.
Since we have a lot of repositories in our organization I would like to keep the runner version in a global environment variable and so when we decide to update the runner version we can simply change it in the environment settings instead of every workflow file.
EDIT
Variables are now supported on organization level. Here the docs
https://docs.github.com/en/actions/learn-github-actions/variables
You can put the value into the GitHub organization secret. Check the following link to get further details:
https://docs.github.com/en/codespaces/managing-codespaces-for-your-organization/managing-encrypted-secrets-for-your-repository-and-organization-for-codespaces#adding-secrets-for-an-organization
Related
I know about organization-wide secrets for GitHub Actions, but I'm looking for a way to define organization-wide non-secret variables, such as default environment variables or something similar.
Sometimes you simply don't want all your shared config to be secret. An example is for AWS credentials, where it may be beneficial to see the AWS_ACCESS_KEY_ID in plain text, but keep the AWS_SECRET_ACCESS_KEY as a secret.
It seems silly to have to put the same AWS_ACCESS_KEY_ID variable as an env variable in every single repo, while the secret half of that pair works perfectly to configure once for the entire organization... Is there such a way?
Perhaps a workaround could be to create a reused workflow action such as set-env that sets the shared environment variables and then include that in each and every job such as uses: my-org/github-actions/.github/workflows/set-env.yml#main, but it's not the cleanest solution I think.
Too bad there's simply not an option next to GitHub action secrets to allow them to be ... well, not so secret.
I am new to CodeQL and therefore my apologies if my question is an obvious one, however, I've been unable to understand a few simple concepts.
Firstly, I can easily configure a public repo with a github action using a yml file configured as follows:
on:
push:
branches: [ master ]
pull_request:
# The branches below must be a subset of the branches above
branches: [ master ]
jobs:
analyze:
name: Analyze
runs-on: ubuntu-latest
permissions:
actions: read
contents: read
security-events: write
strategy:
fail-fast: false
matrix:
language: [ 'java' ]
# CodeQL supports [ 'cpp', 'csharp', 'go', 'java', 'javascript', 'python', 'ruby' ]
# Learn more about CodeQL language support at https://aka.ms/codeql-docs/language-support
steps:
- name: Checkout repository
uses: actions/checkout#v3
# Initializes the CodeQL tools for scanning.
- name: Initialize CodeQL
uses: github/codeql-action/init#v2
with:
queries: +security-extended
languages: ${{ matrix.language }}
# If you wish to specify custom queries, you can do so here or in a config file.
# By default, queries listed here will override any specified in a config file.
# Prefix the list here with "+" to use these queries and those in the config file.
# Details on CodeQL's query packs refer to : https://docs.github.com/en/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning#using-queries-in-ql-packs
# queries: security-extended,security-and-quality
# Autobuild attempts to build any compiled languages (C/C++, C#, or Java).
# If this step fails, then you should remove it and run the build manually (see below)
- name: Autobuild
uses: github/codeql-action/autobuild#v2
# âšī¸ Command-line programs to run using the OS shell.
# đ See https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsrun
# If the Autobuild fails above, remove it and uncomment the following three lines.
# modify them (or add more) to build your code if your project, please refer to the EXAMPLE below for guidance.
# - run: |
# echo "Run, Build Application using script"
# ./location_of_script_within_repo/buildscript.sh
- name: Perform CodeQL Analysis
uses: github/codeql-action/analyze#v2
As indicated in the yaml file, I'm using Java as the language. What I'm trying to then do is trigger a failure / alert with a simple code such as this in Java.
public class Main {
public static void main(String[] args) {
// Example code for https://cwe.mitre.org/data/definitions/476.html
String cmd = System.getProperty("cmd");
cmd = cmd.trim();
}
}
This simple code is an example from Common Weakness Enumeration (CWE) 416 where I'm trying to dereference a variable that hasn't been defined.
If I go to Security -> Code scanning alerts it will show that the scanning was performed but not alerts were found.
Basically, I'm wondering if I need to initialize the CodeQL with a specific CWE under the Initialize CodeQL step in the yaml file.
CodeQL only has a specific set of queries, which do not cover all possible CWEs. This list shows the currently covered CWEs for Java.
As far as I know there exists no query at the moment which detects the specific issue you are showing in your question (there are however queries which detect derefencing null). The reason for this is most likely that it would be difficult to prevent false positives. For example if your application is started with -Dcmd, then the system property would not be null. Similarly there could be a call to System.setProperty in a different part of the application which sets the system property to a non-null value.
Besides that you have configured queries: +security-extended but the type of the query you are looking for (assuming it existed) would most likely be in the query suite security-and-quality because it is not directly security related.
You could also try to write your own queries and then include them in the code scanning workflow. Some concepts of CodeQL might feel a bit unfamiliar at first, but they provide great examples and tutorials for getting started. However, you should probably first check if the provided queries already suffice for your use case.
Since May 2022:
Using CodeQL query packs (and its associated CWE coverage, with query specifiers) is still beta, but not going anywhere
its setup has been simplified:
Code scanning can be set up more easily without committing a workflow file to the repository (Jan. 2023)
Code scanning's new default setup feature automatically finds and sets up the best CodeQL configuration for your repository.
This will detect the languages in the repository and enable CodeQL analysis for every pull request and every push to the default branch and any protected branches.
Default setup currently supports analysis of JavaScript (including TypeScript), Python, and Ruby code.
More languages will be supported soon, and all other languages supported by CodeQL continue to work using a GitHub Actions workflow file.
The new default setup feature is available for CodeQL on repositories that use GitHub Actions.
You can use default setup on your repository's "Settings" tab under "Code security and analysis" (accessible by repository admins and security managers).
The options to set up code scanning using an Actions workflow file or through API upload from 3rd party CI/CD systems remain supported and are unchanged.
This more advanced setup method can be useful if you need to alter the default configuration, for example to include custom query packs.
Default setup configurations can also be converted to advanced setups if your analysis requirements change.
Default setup is currently available at the repository level.
We are actively working on future features at the organization level so you can easily set up code scanning at scale across large numbers of repositories.
This has shipped to GitHub.com and will be available in GitHub Enterprise Server 3.9.
To learn more, read the documentation on setting up code scanning for a repository.
In your case, you would still need an Actions workflow file, to specify a query pack.
Github action workflows automatically redact text in output logs which matches any secrets stored in the relevant action secrets. This works fine for simple cases.
However, I use AWS SSM for storing secrets (for a variety of reasons) - and there are cases where I want to populate the environment for a given step with values from SSM. Unfortunately, actions automatically log the entire environment for every step. Since these secrets aren't official action secrets, GH is unaware that they're sensitive and happily logs them (less happily for me). GH also logs arguments sent to any action step - and many actions require sensitive variables and tokens as arguments.
Is there a way to do this or are GitHub actions essentially unusable if you aren't using their secrets solution?
Yes, you can Mask a value in log
Here is a simple example, where you mask the value in an environment variable, but it can be done with any value:
MY_NAME="Mona The Octocat"
echo "::add-mask::$MY_NAME"
This will tell GitHub whenever you see this value in the output, mask it with ***
If you are implementing an action yourself and use JavaScript in the toolkit/core there is a function to mask logs.
core.setSecret('myPassword');
I am performing the tutorial learn bosh and got a question concerning step Set Deployment Manifest.
Why do I have to set the director_uuid manually in the deployment manifest (which I then upload to the very same director)? Is this a security feature?
According to the document, director_uuid is for CLI to operate target Director.
Deployment Identification
name [String, required]: The name of the deployment. A single Director
can manage multiple deployments and distinguishes them by name.
director_uuid [String, required]: This string must match the UUID of
the currently targeted Director for the CLI to allow any operations on
the deployment. Use bosh status to display the UUID of the currently
targeted Director.
Refer to: BOSH documentation
Cloud Foundry can provide Cloud Service like PaaS. If you deploy a manifest to the wrong environment that means your customer's environment could break down.
That complicated parameter helps you to avoid miss operation in your operational environment.
I'm using Jenkins 1.554.3 and specifying conditional action for Flexible publish as a post build step.
Looking on the list of available actions I can see that it contains only post-build steps.
How I can update this list with the list with the actions available from build steps and specify as action for Flexibly publish post build step?
Thank you.
Use Jenkins Any Build Step plugin. It allows to use Publishers (post-build actions) as Build Steps and vice-versa.
Then, under Jenkins Global Configuration, there is a Flexible Publish section. Set the value to Any build step. This will allow build steps under post-build actions.
For the sake of completeness, to allow post-build action under build steps, there is a section Conditional buildstep. Set the value there to Any build step too.