It seems to me that you can only see the vulnerable dependencies on the master branch. I fixed those mentioned in the alert on a separate branch and want to check if in fact the vulnerable dependencies are fixed, so what I really need is to be able to check the alert for the specific branch, can this be done?
I had this same issue.
The problem with GitHub's Security Alert feature is that it will always scans the default branch of a repository. This is normally the master branch. Therefore, any changes to resolve security issues made to other branches will not be recognised by GitHub.
The workaround.
You can change the default branch to be any branch in your repository! Including the one you have done the work to resolve the security issues.
On GitHub, navigate to the main page of the repository.
Under your repository name, click Settings.
In the left menu, click Branches.
Choose the new default branch.
Once you have changed the default branch to the branch you have done the resolving work on, GitHub's Security Alert feature will start to scan that branch.
And you should see the security alerts that you have resolved disappear.
Afterwards you can change the default branch back to the master branch and only change it when you are specifically working on resolving security vulnerabilities.
The security alerts for vulnerable dependencies reported by GitHub might be valid only for the default branch (usually master, but you can change it).
If you are not ready to merge your fix to the default branch of your repo, one workaround would be to push that branch to the default (again, usually master) branch of a new dedicated (and temporary) repository, just to check if any new alerts are detected on that new repo.
Update Oct. 2020, 2+ years later: Michael Greisman points out in the comments to this GitHub Community answer and the documentation "About alerts for vulnerable dependencies".
It confirms that the scan is done against the default branch.
"Once the fix... is merged into the default branch... GitHub will schedule a new scan of your project’s dependencies".
Related
I'm not certain what happened. Somehow "main" didn't get set as the default branch at the origin. It got set to an old branch that I've long since moved beyond. Though I see in the settings where I can switch the default branch, GitHub presents a big, scary warning that says:
"Changing your default branch can have unintended consequences that can affect new pull requests and clones."
What's the actual danger here? Or is there a way to just recreate the origin repository at GitHub from my local repository? This is just a personal thing that I'm working on. No worries about collaborators.
There is no real issue in your case, for a personal repository.
You can use a gh repo edit --default-branch main (using the GitHub CLI gh, to be installed first), if executed from your local repository folder.
Our implementation of GitHub is very basic.
We have one master branch (default) and then one open branch (DEV) for new developments.
Ideally we won't have more than one branch open at the same time.
Master branch is a protected branch so only admin can do changes on there.
The idea is to use GitHub Desktop to manage the developments locally in a computer as it would be too complex to manage it via the WebUI due to the kind of files being used.
Also we have the challenge that team is mostly consultant/external and rotating, so not everyone is familiar with the GitHub funcitonality...
Due to this, I would like to know if it is possible to avoid checking out the master branch when cloning our repository.
I am mainly aiming for this approach as I have problems when someone clones the repository locally and starts developing into the local master branch (without switching to the DEV branch first) and getting the error when pushing to server (due to the protected branch).
At that point the developer has already developed a lot and now is time for him to switch all his development to the proper branch instead of using the master one...
Is there any way to achieve that initial checkout from master to be avoided?
EDIT:
just immediately after posting I thought on changing the default branch to DEV so when someone clones it will always be directly targeted to the DEV branch instead of master...
Would this have any bad consequence for such a simple implementation?
Note that branch is created by admin as well as deleting it after pull request has been merged...
So this could be his responsibility to change the default branch every time a new development needs to be done and move it back to the master when development is finished...
Does it have sense?
When you clone a repository, whatever is "checked out" on the remote end becomes the default branch that is checked out on the local end.
For remote bare repositories, which is usually the norm, you have a "default branch" configuration that is used. In your case this is set to master.
You can change this on github to be DEV instead, so that fresh clones of the repository checks out DEV by default instead of master.
You do this by navigating to your repository on github, and click on the "X branches" button that is just to the right of the button/dropdown that shows the default branch selection on your repository page:
on the page that shows branches, click on the "Change default branch" button to the right of your current default branch:
and then finally select your new default branch and click Update:
I would like to configure my github repository such that I can receive security alerts if a vulnerability is detected on any branch, not just the master branch. Does anyone know how and where to make this configuration.
The workflow we use to introduce new changes to our project is the following
Create a feature branch to develop a change
By way of pull request, merge the feature branch changes into a develop branch
Build a test instance of the application from the develop branch
Verify the change in the test instance
Cherry pick the change from the develop branch.
Deploy the production instance from master branch
in a recent change we introduced a security vulnerability and we only received a github alert when the change was cherry-picked to the master branch. Can I configure github to do security scans on all the branches, or perhaps the develop branch along with master?
It looks like my question was previously asked, and there is an answer here: github vulnerable dependencies per branch
GitHub security scans occur on the default branch of a repository.
I'm having an issue where GitHub doesn't automatically rebase/merge my pull requests at all, even if commits to master since the PR branch was created don't even touch the same files the PR itself touches, so there aren't any merge conflicts at all.
I know this is possible in GitHub, I've encountered a few repositories myself where PRs don't require a rebase and merge conflicts are automatically resolved.
The repository in question is here.
I've tried going through the project settings but I cannot seem to find a setting that says that this is an issue. Also, if I rebase my PRs manually, it usually happens automatically without me being prompted to resolve any conflics.
This is configured in the required status checks section, found in Settings → Branches → Protected Branches. The relevant setting is "Require branches to be up to date before merging".
If this feature is enabled, and status checking is set to "strict" (it is by default), then
you'll need to bring the head branch up to date after other collaborators merge pull requests to the protected base branch.
My current employer uses clearcase (I believe Base-CC) for version control. Our project has a branch, and each user has his own branch on top of it. The configspec of the users shows elements from the user branch, then from the project branch, and then from the company-wide branch.
The current modus-operandi, is that the users merge in their changes back to the project branch, and keep working on their own branch.
The problem is, that after the user merges his changes, he still has a branch for this element. Then, when the someone else modifies the project, he still sees his outdated version.
I want the following:
if a user has a checkedout file, display it.
if a user has unmerged worked, display it.
if a user has merged work, show the lastest version from the project
I thought of marking the element branch as obsolete after each merge, but the users still sees it, and not the latest from the project.
Then I thought of changing the config spec, to somehow ignore merged-in branches, but I do not know how to do that.
Any ideas?
You can reuse your personal dev branch, but the correct workflow, when a dev merges his/her branch to the upstream branch (here the project one) is:
first merge the project branch to the personal dev branch
resolve any conflict locally
then merge personal dev to project.
That way:
you don't have to modify the config spec after each merge,
you make sure the merge will be a trivial one,
and the personal dev branch can represent easily the LATEST from the upstream branch after merging (again) the project branch to the personal dev branch: the delta will be minimal.