Earlier quoted context omitted.
As far as I can see they also have access to your secrets. I really haven't gotten myself to use any non-GitHub-defined Actions yet, because I haven't been able to verify if that's actually safe.
They don't have direct access. You need to assign the secret in your workflow file. Example: steps: - uses: actions/checkout@v2 - uses: sfdx-actions/setup-sfdx@v1 with: sfdx-auth-url: ${{ secrets.SFDX_AUTH_URL }} or steps: - uses: actions/checkout@v2 - name: Run deployment script env: HEROKU_API_TOKEN: ${{ secrets.HEROKU_API_TOKEN }} The first is for an Action, the second is for a normal workflow script.
Code scanning for security vulnerabilities now available
121–125 of 125 posts
Re: Code scanning for security vulnerabilities now available
#122In the not-so-distant future: Code snippet scanning for copyright infringement or Stack Overflow attribution. 2 years? 4?
>In the not-so-distant future: Code snippet scanning for copyright infringement Will never happen. Can you imagine what would occur if Github started harrassing private repo owners for including GPL licensed code? Or automatically making them public? All their customers would bolt immediately. Copyright infringement is Github's bread and butter. Stack Overflow attribution is equally unlikely. The same group that says…
Why would Github do that? It's perfectly fine to not distribute code you received under the GPL. The license just says that if you do distribute the code in binary, you must provide recipients with the source as well.
Re: Code scanning for security vulnerabilities now available
#123Earlier quoted context omitted.
Webpack generates code which might be loaded by users and additionally it's very common to run it on a CI server (which can sometimes have network access out to other machines at a firm). In general, it's quite strange to me that vulnerabilities in `devDependencies` are considered less important than those in `dependencies`. These dependencies are generally for tools that are run within your company network, and cont…
What would be the attack vector in this case? Assuming that it's a vulnerability rather than an actually malicious package, how would an attacker exploit something running on your CI server? The only way I see is if they already have the ability to modify your source code, at which point it's of course already game over.
Re: Code scanning for security vulnerabilities now available
#124Earlier quoted context omitted.
At some point many beginner devs migrated from StackOverflow to Github because their really bad question were being closed there, and now they just overwhelm open source authors I'm glad it's not just me seeing this - My repos aren't even that popular and some of the issues just seem to be "help me build my project..."
I started just quoting them back prices when they send me random emails like that. What'd you think, they disappear quickly!
Re: Code scanning for security vulnerabilities now available
#125Earlier quoted context omitted.
PM from GitHub here. We're adding Ruby support to CodeQL (the scanning engine used in code scanning by default). It's our top requested language, and one we use extensively internally. Adding each new language to CodeQL takes about 6-9 months and needs a team to maintain it in perpetuity, which is why we don't have it yet, but we're starting that work now. The other languages we hear the most demand for CodeQL suppor…
Is the CodeQL project itself open source? I would love to contribute support for Elixir.