New threat model for dev clone for CVE-2024-32002

One of #QA's goals is to produce code without any #vulnerabilities, ensuring a clean code with no #flaws. To achieve this, we have recently at AlphaApps integrated the #veracode powerful scanning tool into our process for added #security and to identify any potential vulnerabilities that need to be addressed automatically. However, we encountered some issues as the Veracode CLI does not support yet uploading and pre-scanning the code with reporting on Veracode dashboard. To overcome this, we used #HTTPie with #HMAC authorization in our Gitlab pipelines to meet the requirements. The following steps helped us achieve this: 1. Package our Python project using the veracode CLI to avoid any odd files in the generated package. 2. Upload the zip file using HTTPie in the "uploadlargefile.do" call. 3. Pre-scan the zip file by calling "beginprescan.do" with the auto-scan parameter enabled to minimize the time of the pipeline. 4. Build the image and push it to ACR, while sending an email with the SHA256 of the image and Veracode Scan Name. This helps easily determine the related code in the Veracode report before making a decision to deploy that docker image. If there are any questions, please feel free to raise them and I will be ready to provide more details. 🙌 #veracode #vulnerabilities #flaws #security #autoscan #pipeline #qa #scan #azure #acr #docker #clean #code #xmlapi

when an RCE vulnerability in widely used and often poorly monitored tools arises, it is generally a good idea to be aware of it and share it with those in your organization. The latest is with Git, a free and open-source distributed version control system (VCS) , which allows every developer to have a full copy of the repository on their local machine. Critical Git vulnerability (CVE-2024-32002) allows RCE when cloning repositories with submodules. Researchers from Halborn have developed an exploit kit - https://lnkd.in/gR2i-ypx the following researcher as well: https://lnkd.in/gDngYNEb

You’ve spent hours debugging a tricky bug. You can reproduce it but can’t quite figure out the root cause. You’re starting to believe that the bug might not be in your code, but in the library you are using. Given how much time you’ve already spent on this investigation, you are getting desperate and want to ask for help. What’s the best way to do it? Create a minimal repro! Read more here: https://lnkd.in/gNMucN6b

Enumerate and diff capabilities of all files in a repository (and compiled artifacts)! 📦🔍  https://lnkd.in/gxyExx4d #testing

Amidst all of my ramblings about Bash, I wrote an article on using ShellCheck. If you are interested in that sort of thing check it out :) https://lnkd.in/dWfz6t2Y

🎉 I'm thrilled to share my first write-up for Jobert Abma's vulnerable-codes lab on GitLab! In this comprehensive guide, I delve into exploiting 15 of the most notorious web vulnerabilities using Bash scripts. Here are the vulnerabilities covered: 1. Blind SQL Injection 2. Command Injection 3. Cross-Origin Resource Sharing (CORS) 4. DOM Clobbering 5. Insecure Direct Object References (IDOR) 6. Open Redirect 7. Path Traversal 8. Remote Code Execution (RCE) 9. SQL Injection 10. SSRF DNS Rebinding 11. Server-Side Request Forgery (SSRF) 12. Server-Side Template Injection (SSTI) 13. Unserialize 14. Cross-Site Scripting (XSS) 15. XML External Entity (XXE) I'm eager to continue expanding my knowledge and skills in this field. Looking forward to seeing where this journey takes me in the coming years. Explore the GitLab: https://lnkd.in/d9Ye2wCm Read my write-up: https://lnkd.in/d5WHk6je

Lunch time thought Whilst I love that git is a wonderful event sourced distributed ledger I also like that its criminal to rewrite commits because of this But I also hate that once again I committed something I wish I hadn't and now i have to go change the roles This to me smells of a design problem - how can we as an industry be exposing ourselves to this risk like this? There has to be a better way. There is a usability problem in here - I know better, but when going fast it is excruciatingly easy to miss something. I keep seeing console *commands* with *secure data* in them that should never be there. We have a system that has bad cohesion. The command changes as the API changes The secure data changes when the organisation changes But our API munge these to seperate reasons for change together into a single command. Should we start giving examples of things like that that depend upon env vars only? What do you think? #CI #ContinuousImprovement #XP #Security Sure pre-commit hooks are great - but when github actions are easy to edit inline we really need something to check for id like strings and really interrogate us wrt comitting them.

One of the benefits of using #containers is that you can bring the power of battle-tested libraries from other programming languages to your project, no matter which programming language you use to write them. And if you already use #testcontainers, if creating a module for that library in your language, it allows you to avoid using a non-as-mature library in your ecosystem. In example: migrating databases is a recurrent "problem" in any project. But which tool to use? There are many of them across all languages, some more mature, some less. In the Java ecosystem, there exists #flywaydb, which is extremely powerful and very well integrated in the Java frameworks. Would you like to use it in your Go projects? Well, had a #testcontainers module for it existed, why not? Thanks to the CyberOwl team, specially to Kevin Taylor, that Flyway module for Testcontainers Go is ons its way, and it works smooooothly well in testing a postgres migration in Go. 🔎 want to take a look at the code and examples? https://lnkd.in/dvigmbaq #testcontainers #golang #modules #testing #database #migrations

#Celery #Flower #VersionsIncompatibility Few days ago, we faced a small problem with one of our applications, the deployment failed and our workers/processes do not run properly due to the version incompatibility issues between Celery and Flower. This small hiccup turned into an insightful debugging session that helped us identify and resolve the conflict. 🔧💡 If you’re working with Celery and Flower, or simply curious about managing version dependencies effectively, check out our latest blog post: Troubleshooting Celery and Flower Compatibility Issues: https://lnkd.in/gEyFmaKH 👉 Read the full story and learn how we tackled the issue! #Debugging #TechTips #Python #Glinteco

I found my first CVE! It is a remote code execution issue in PyLoad. More details on my blog: https://lnkd.in/gVsDZbeU