TV Time's parent company criticized Apple's App Store control after the tech giant removed its streaming app over an intellectual property dispute. "Apple holds significant power over app developers by controlling access to a massive market and, in this case, seems to have acted on a complaint without requiring robust evidence from the complainant," Jerry Inman, CMO of Whip Media, which operates the app, told TechCrunch.

The app was pulled from the store by Apple after the developer refused to pay a settlement fee related to user-uploaded cover art. The app has since been reinstated.

Slashdot readers damn_registrars and GFS666 share the news of the passing of Thomas E. Kurtz, co-inventor of the BASIC programming language back in the 1960s. He was 96. Hackaday reports: The origins of BASIC lie in the Dartmouth Timesharing System, like similar timesharing operating systems of the day, designed to allow the resources of a single computer to be shared across many terminals. In this case the computer was at Dartmouth College, and BASIC was designed to be a language with which software could be written by average students who perhaps didn't have a computing background. In the decade that followed it proved ideal for the new microcomputers, and few were the home computers of the era which didn't boot into some form of BASIC interpreter. Kurtz continued his work as a distinguished academic and educator until his retirement in 1993, but throughout he remained as the guiding hand of the language.

The goal? "Make C++ and Rust interoperability easily accessible and approachable to the widest possible audience." And the Rust Foundation's "Interop Initiative" is specifically focused on the goal of interoperability "within the same executable," through either inline embedding that allows "integrated compilation", or foreign function interfaces.

To that end, a statement addressing "the challenges and opportunities in C++ and Rust interoperability" was announced this week by the Rust Foundation. Pointing out that the "Interop Initiative" was launched in February 2024 with a $1M contribution from Google, it now "proposes a collaborative, problem-space approach engaging key stakeholders from both language communities.

"Rather than prescribing specific solutions, this problem statement serves as a foundation for community input and participation in shaping both the strategic direction and tactical implementation of improved C++/Rust interoperability."

Their official problem statement outlines three "key strategic approaches."

- Improve existing tools and address tactical issues to reduce interoperability friction and risk in the short term.

- Build consensus around long-term goals requiring changes to Rust itself and develop the tactical approaches to begin pursuing them.

- Engage with the C++ community and committee to improve the quality of interoperation for both languages to help realize the mutual goals of safety and performance.

And it argues that interoperability "is essential to pursuing safety and performance which is maintainable and scalable." A significant amount of development has gone into libraries to facilitate interoperability with both C and C++, but from the language and compiler level, the situation remains largely unchanged from the early days of Rust. As the desire to integrate Rust into more C++ codebases increases, the value of making C++/Rust interoperability safer, easier, and more efficient is rapidly increasing. While each language takes a different overall approach, both view safety as an essential concern in modern systems. Both Rust and C++ have language- and standard-library-level facilities to improve safety in seemingly compatible ways, but significant benefits are lost when transiting the foreign function interfaces (FFI) boundary using the C ABI...

The consequence of this increased cost to interoperate means both C++ and Rust codebases are less able to access valuable code that already exists in the other language, and the ability to transition system components from one language to another is reduced outside of existing C-like interface boundaries. Ultimately, this reduction in freedom leads to worse outcomes for all users since technologists are less free to choose the most effective solutions.

The Tiobe index tries to track the popularity of programming languages by counting the number of search results for the language's name followed by the word "programming" (on 25 different search engines). And this month there were some surprises...

By TIOBE's reckoning, compared to a year ago PHP has now fallen from #7 to #12, while Delphi/Object Pascal shot up five spots from #16 to #11. In that same year, Fortran jumped from #12 to #8 — while both Visual Basic and SQL dropped down a single rank. Toward the top of the list, C actually fell from the #2 spot over the last 12 months to the #4 spot.

And Go just reached the #7 rank on the TIOBE's ranking of programming language popularity — "an all time high for Go," according to TIOBE CEO Paul Jansen. In this month's note, he explains what he thinks is unusual about this — starting by saying that Go programs are both fast, and easy in many ways — easy to deploy, easy to learn, and easy to understand. Python for instance is easy to learn but not fast, and deployment for larger Python programs is fragile due to dependencies on all kind of versioned libraries in the environment.

If compared to Rust for instance (another contender for a top position), Go is a tiny bit slower, but the Go programs are much easier to understand. The next hurdle for Go in the TIOBE index is JavaScript at position #6. That will be a tough one to pass. JavaScript is ubiquitous in software development, although for larger JavaScript systems we see a shift to TypeScript nowadays.
"If annual trends continue this way, Go will bypass JavaScript within 3 years," TIOBE's CEO predicts. (Adding "Let's see what the future has in store for Go...") Although the Go team actually has specific plans for the future, according to a blog post this week celebrating Go's 15th anniversary: We're working on making Go better for AI — and AI better for Go — by enhancing Go's capabilities in AI infrastructure, applications, and developer assistance. Go is a great language for building production systems, and we want it to be a great language for building production AI systems, too... For AI applications, we will continue building out first-class support for Go in popular AI SDKs, including LangChainGo and Genkit. And from its very beginning, Go aimed to improve the end-to-end software engineering process, so naturally we're looking at bringing the latest tools and techniques from AI to bear on reducing developer toil, leaving more time for the fun stuff — like actually programming!
TIOBE's top 10 programming language rankings for the month of November:

1. Python
2. C++
3. Java
4. C
5. C#
6. JavaScript
7. Go
8. Fortran
9. Visual Basic
10. SQL

Google's transistion to Safe Coding and memory-safe languages "will take multiple years," according to a post on Google's security blog. So "we're also retrofitting secure-by-design principles to our existing C++ codebase wherever possible," a process which includes "working towards bringing spatial memory safety into as many of our C++ codebases as possible, including Chrome and the monolithic codebase powering our services." We've begun by enabling hardened libc++, which adds bounds checking to standard C++ data structures, eliminating a significant class of spatial safety bugs. While C++ will not become fully memory-safe, these improvements reduce risk as discussed in more detail in our perspective on memory safety, leading to more reliable and secure software... It's also worth noting that similar hardening is available in other C++ standard libraries, such as libstdc++. Building on the successful deployment of hardened libc++ in Chrome in 2022, we've now made it default across our server-side production systems. This improves spatial memory safety across our services, including key performance-critical components of products like Search, Gmail, Drive, YouTube, and Maps... The performance impact of these changes was surprisingly low, despite Google's modern C++ codebase making heavy use of libc++. Hardening libc++ resulted in an average 0.30% performance impact across our services (yes, only a third of a percent) ...

In just a few months since enabling hardened libc++ by default, we've already seen benefits. Hardened libc++ has already disrupted an internal red team exercise and would have prevented another one that happened before we enabled hardening, demonstrating its effectiveness in thwarting exploits. The safety checks have uncovered over 1,000 bugs, and would prevent 1,000 to 2,000 new bugs yearly at our current rate of C++ development...

The process of identifying and fixing bugs uncovered by hardened libc++ led to a 30% reduction in our baseline segmentation fault rate across production, indicating improved code reliability and quality. Beyond crashes, the checks also caught errors that would have otherwise manifested as unpredictable behavior or data corruption... Hardened libc++ enabled us to identify and fix multiple bugs that had been lurking in our code for more than a decade. The checks transform many difficult-to-diagnose memory corruptions into immediate and easily debuggable errors, saving developers valuable time and effort.
The post notes that they're also working on "making it easier to interoperate with memory-safe languages. Migrating our C++ to Safe Buffers shrinks the gap between the languages, which simplifies interoperability and potentially even an eventual automated translation."

Longtime Slashdot reader DaPhil writes: I taught myself to code at 12 years old in the 90s and I've always liked the back-and-forth with the runtime to achieve the right result. I recently got back from other roles to code again, and when starting a new project last year, I decided to give the new "AI assistants" a go.

My initial surprise at the quality and the speed you can achieve when using ChatGPT and/or Copilot when coding turned sour over the months, as I realized that all the joy I felt about trying to get the result I want -- slowly improving my code by (slowly) thinking, checking the results against the runtime, and finally achieving success -- is, well, gone. What I do now is type English sentences in increasingly desperate attempts to get ChatGPT to output what I want (or provide snippets to Copilot to get the right autocompletion), which -- as they are pretty much black boxes -- is frustrating and non-linear: it either "just works," or it doesn't. There is no measure of progress. In a way, having Copilot in the IDE was even worse, since it often disrupts my thinking when suggesting completions.

I've since disabled Copilot. Interestingly, I myself now feel somehow "disabled" without it in the IDE; however, the abstention has given me back the ability to sit back and think, and through that, the joy of programming. Still, it feels like I'm now somehow an ex-drug addict always on the verge of a relapse. I was wondering if any of you felt the same, or if I'm just... old.

Phoronix's Michael Larabel reports: The OpenMP Architecture Review Board announced from SC24 that OpenMP 6.0 is now available as a major upgrade to the OpenMP specification for multi-process programming within C / C++ / Fortran. A big emphasis on OpenMP 6.0 is making it easier for developers to embrace. OpenMP 6.0 aims to make it easier to support parallel programming in new applications, easier to adapt to new use-cases, and more fine-grained developer control.

OpenMP 6.0 simplifies task programming with support for task execution by free-agent threads, allowing for recording of task graphs for efficient replay, and other improvements. OpenMP 6.0 also brings support for array syntax applications, better control over memory allocations and accessibility, easier writing of asynchronous data transfers, and other improvements for enhanced device support / offloading. There is also easier programming of loop transformations, support for induction, support for C23 / Fortran 2023 / C++23, grater user control of storage resources and memory spaces, and other improvements.

Mark Rainey: Engineers are currently debugging why the Voyager 1 spacecraft, which is 15 billions miles away, turned off its main radio and switched to a backup radio that hasn't been used in over forty years!

I've had some tricky debugging issues in the past, including finding compiler bugs and debugging code with no debugger that had been burnt into prom packs for terminals, however I have huge admiration for the engineers maintaining the operation of Voyager 1.

Recently they sent a command to the craft that caused it to shut off its main radio transmitter, seemingly in an effort to preserve power and protect from faults. This prompted it to switch over to the backup radio transmitter, that is lower power. Now they have regained communication they are trying to determine the cause on hardware that is nearly 50 years old. Any communication takes days. When you think you have a difficult issue to debug, spare a thought for this team.

Paul Kinlan, who leads the Chrome and the Open Web Developer Relations team at Google, asks and answers the question (with a no.): Frameworks are abstractions over a platform designed for people and teams to accelerate their teams new work and maintenance while improving the consistency and quality of the projects. They also frequently force a certain type of structure and architecture to your code base. This isn't a bad thing, team productivity is an important aspect of any software.

I'm of the belief that software development is entering a radical shift that is currently driven by agents like Replit's and there is a world where a person never actually has to manipulate code directly anymore. As I was making broad and sweeping changes to the functionality of the applications by throwing the Agent a couple of prompts here and there, the software didn't seem to care that there was repetition in the code across multiple views, it didn't care about shared logic, extensibility or inheritability of components... it just implemented what it needed to do and it did it as vanilla as it could.

I was just left wondering if there will be a need for frameworks in the future? Do the architecture patterns we've learnt over the years matter? Will new patterns for software architecture appear that favour LLM management?

Google's head of research Yossi Matias maintains that learning to code remains "as important as ever" despite AI's growing role in software development. While AI tools have reduced coding time for some developers -- and Alphabet CEO Sundar Pichai noting that AI now generates a quarter of all code, Matias stressed that human engineers still review and approve AI-generated code.

The Google executive, who also serves as a company VP, acknowledged that junior professionals have faced challenges gaining experience as AI handles entry-level tasks. Google has launched initiatives to support early-career employees through this transition. Matias compared coding literacy to basic mathematics, arguing it provides crucial understanding of technology regardless of career path.

"Java application security would be enhanced through two proposals aimed at resisting quantum computing attacks," reports InfoWorld, "one plan involving digital signatures and the other key encapsulation." The two proposals reside in the OpenJDK JEP (JDK Enhancement Proposal) index.

The Quantum-Resistant Module-Lattice-Based Digital Signature Algorithm proposal calls for enhancing the security of Java applications by providing an implementation of the quantum-resistant module-latticed-based digital signature algorithm (ML-DSA). ML-DSA would secure against future quantum computing attacks by using digital signatures to detect unauthorized modifications to data and to authenticate the identity of signatories. ML-DSA was standardized by the United States National Institute of Standards and Technology (NIST) in FIPS 204.

The Quantum-Resistant Module-Lattice-Based Key Encapsulation Mechanism proposal calls for enhancing application security by providing an implementation of the quantum-resistant module-lattice-based key encapsulation mechanism (ML-KEM). KEMs are used to secure symmetric keys over insecure communication channels using public key cryptography. ML-KEM is designed to be secure against future quantum computing attacks and was standardized by NIST in FIPS 203.

Nathan Sobo "joined GitHub in late 2011 to build the Atom text editor," according to an online biography, "and he led the Atom team until 2018." Max Brunsfeld joined the Atom team in 2013, and "While driving Atom towards its 1.0 launch during the day, Max spent nights and weekends building Tree-sitter, a blazing-fast and expressive incremental parsing framework that currently powers all code analysis at GitHub."

Last year they teamed up with Antonio Scandurra (another Atom alumnus) to launch a new startup called Zed (which in 2023 raised $10 million, according to TechCrunch). And today the open source blog It's FOSS checks in on their open-source code editor — "Zed Editor". Mainly written in Rust, it supports running in CLI, diagnosing project-wide errors, split panes, and markdown previews: By default, any added content is treated as plain text. I used the language switcher to change it to Rust so that I would get proper syntax highlighting, indentation, error detection, and other useful language-specific functions. The switch highlighted all the Rust elements correctly, and I then focused on Zed Editor's user interface. The overall feel of the editor was minimal, with all the important options being laid out nicely.

[Its status bar] had some interesting panels. The first one I checked was the Terminal Panel, which, as the name suggests, lets you run commands, scripts, and facilitates interaction with system files or processes directly from within the editor. I then moved to the Assistant Panel, which is home to various large language models that can be integrated into Zed Editor. There are options like Anthropic, GitHub Copilot Chat, Ollama, OpenAI, and Google AI... The Zed Editor team has also recently introduced Zed AI in collaboration with Anthropic for assisting with coding, allowing for code generation, advanced context-powered interactions, and more...

The real-time collaboration features on Zed Editor are quite appealing too. To check them out, I had to log in with my GitHub account. After logging in, the Collab Panel opened up, and I could see many channels from the official Zed community. I could chat with others, add collaborators to existing projects, join a call with the option to share my screen and track other collaborators' cursors, add new contacts, and carry out many other collaborative tasks.

One can also use extensions and themes to extend what Zed Editor can do. There are some nice pre-installed themes as well.

"The Rust trademark policy has been updated and a new draft is available to view," announced the Rust Foundation this week.

The last proposed trademark policy (in April of 2023) was criticized by open source advocate Bruce Perens in The Register as "far awry of fair use which is legally permitted." The Rust Foundation says this new version has "incorporated a number of suggestions from the Rust community," in a blog post that summarizes the feedback and enumerates specific ways it's been addressed: 1. We primarily plan to lean on community reports for enforcement and have no intention of spending our limited resources policing the work of small creators.

2. We have removed the non-legal language summary and instead have clarified wording throughout as best we can while keeping the policy valid.

3. The Rust trademark does not cover use of the word "Rust" in general and instead pertains to its use in relevant technical settings.

4. We have updated the logo usage policy. Color modifications are allowed.

5. The non-endorsement rule is about managing perception of official affiliation with the Foundation and Rust Project, and is thus subjective.

6. We removed restrictions on the use of "Rust" and "Cargo" in package names. The crates prefixes "rust-" and "cargo-" are no longer reserved to the Rust Project.

7. We will usually allow the community to use the marks on limited merchandise (more details in the updated draft)....

[T]he central purpose of these updates is to empower all Rustaceans to engage with the Rust language ecosystem more confidently. As a final step in this process, we invite you to review the updated policy and share any blocking concerns you might have... Thank you to everyone who weighed in with helpful suggestions on the initial trademark policy draft we shared. The level of engagement and passion within the Rust community is inspiring to all of us at the Rust Foundation.
The tech news site Heise Online writes "It is noticeable that the language is much clearer and dispenses with a lot of legal jargon," in a piece which argues the new draft "should calm the waves and create clarity." The new draft is not only formulated more simply, but is also significantly shorter. Some restrictions have been softened in the new rules or have disappeared completely...

Meanwhile, the Foundation has also adapted its logo so that it is clear which logo stands for the programming language and which for the Foundation. The use of the name Rust is explicitly permitted to identify projects that are either written in the programming language or are compatible with it...

Before the new trademark rules come into force, the Rust Foundation is collecting feedback on the current draft. The web form is open until November 20, 2024.

An anonymous reader quotes a report from Oregon Live: Intel told employees this week that it will bring back free coffee and tea at its work sites, one of many benefits the chipmaker eliminated last summer as it sought to slash $10 billion from its annual budget. "Although Intel still faces cost challenges, we understand that small comforts play a significant role in our daily routines," Intel wrote on its internal messaging forum, called Circuit. "We know this is a small step, but we hope it is a meaningful one in supporting our workplace culture." Intel declined comment. The company did not resume offering free fruit, another perk eliminated last summer. Employees say privately that morale has been devastated by Intel's poor financial performance and by cutbacks aimed at returning the business to profitability.

[...] Christy Pambianchi, Intel's chief people officer, told employees that Intel had been spending $100 million annually on free and discounted food and beverages and couldn't afford to keep doing that. "Until we get into a better financial health position, we need to be suspending those," Pambianchi said, according to an account of the meeting reviewed by The Oregonian/OregonLive. By Wednesday the company had reversed itself, committing to keep its employees caffeinated. In August, Intel announced plans to lay off over 16,000 employees, representing more than 15% of its global workforce. Its stock dropped to a 50-year low following the announcement. Starting November 8, Nvidia will replace the chipmaker on the Dow Jones Industrial Average.

I had the opportunity to interview esteemed programmer Steve Yegge for the SourceForge Podcast to ask him all about AI-powered coding assistants and the future of programming. "We're moving from where you have to write the code to where the LLM will write the code and you're just having a conversation with it about the code," said Yegge. "That is much more accessible to people who are just getting into the industry."

Steve has nearly 30 years of programming experience working at Geoworks, Amazon, Google, Grab and now SourceGraph, working to build out the Cody AI assistant platform. Here's his Wikipedia page. He's not shy about sharing his opinions or predictions for the industry, no matter how difficult it may be for some to hear. "I'm going to make the claim that ... line-oriented programming, which we've done for the last 40, 50 years, ... is going away. It is dying just like assembly language did, and it will be completely dead within five years."

You can watch the episode on YouTube and stream on all major podcast platforms. A transcription of the podcast is available here.

Software engineer David Gomes writes in a blog post: I sometimes need to search for a website that will "convert a PNG to SVG", or "remove page from PDF" or "resize svg". And these apps are... okay. I don't really trust most of them with my data, and also a lot of times they just don't work or have too many ads. So, I've been noticing a trend of people just using AI agents to create full blown apps for these simple use cases.

I decided to try it myself for a "resize SVG" app since I recently had to go through a bunch of websites to do this. So, I pulled up Replit Agent and even though I've used it before, it doesn't cease to amaze me just how insanely good it is. The level of polish on this product is unlike any other AI agent out there right now. It starts off by drawing up a plan and asking you for feedback on that plan. Then, it'll just go to town and try to build the app. But what's super clever about it is that the agent asks you for feedback along the way. Effectively, the Replit Agent guides you, not the other way around (as one might have expected).

Anton Shilov reports via Tom's Hardware: FFmpeg is an open-source video decoding project developed by volunteers who contribute to its codebase, fix bugs, and add new features. The project is led by a small group of core developers and maintainers who oversee its direction and ensure that contributions meet certain standards. They coordinate the project's development and release cycles, merging contributions from other developers. This group of developers tried to implement a handwritten AVX512 assembly code path, something that has rarely been done before, at least not in the video industry.

The developers have created an optimized code path using the AVX-512 instruction set to accelerate specific functions within the FFmpeg multimedia processing library. By leveraging AVX-512, they were able to achieve significant performance improvements -- from three to 94 times faster -- compared to standard implementations. AVX-512 enables processing large chunks of data in parallel using 512-bit registers, which can handle up to 16 single-precision FLOPS or 8 double-precision FLOPS in one operation. This optimization is ideal for compute-heavy tasks in general, but in the case of video and image processing in particular.

The benchmarking results show that the new handwritten AVX-512 code path performs considerably faster than other implementations, including baseline C code and lower SIMD instruction sets like AVX2 and SSSE3. In some cases, the revamped AVX-512 codepath achieves a speedup of nearly 94 times over the baseline, highlighting the efficiency of hand-optimized assembly code for AVX-512.

App developers Musi and Sarafan Mobile have sued Apple and Google in California federal court over app removals they claim were unjustified, highlighting tensions over the tech giants' intellectual property enforcement policies. Musi's music-streaming app was removed after YouTube complained about interface infringement, while Sarafan's "Reely" app was taken down following Instagram's claims about logo similarity.

Both developers say the platforms breached their agreements by removing apps without sufficient evidence. The lawsuits underscore broader concerns about Apple and Google's dominance in app distribution. Their private IP dispute systems operate outside traditional legal frameworks, with platforms making unilateral decisions that can effectively shut down businesses, according to University of New Hampshire law professor Peter Karol. [...]

"In a court proceeding, you can see here's a complaint with the allegations, and then we have the defendant respond, and then we have a judge come out with an opinion saying, 'Is the mark valid? Is the mark infringed?'" said Lisa Ramsey, law professor at University of San Diego. Google and Apple's systems, meanwhile, are "a black box."

GitHub released its annual "State of the Octoverse" report this week. And while "Systems programming languages, like Rust, are also on the rise... Python, JavaScript, TypeScript, and Java remain the most widely used languages on GitHub."

In fact, "In 2024, Python overtook JavaScript as the most popular language on GitHub." They also report usage of Jupyter Notebooks "skyrocketed" with a 92% jump in usage, which along with Python's rise seems to underscore "the surge in data science and machine learning on GitHub..." We're also seeing increased interest in AI agents and smaller models that require less computational power, reflecting a shift across the industry as more people focus on new use cases for AI... While the United States leads in contributions to generative AI projects on GitHub, we see more absolute activity outside the United States. In 2024, there was a 59% surge in the number of contributions to generative AI projects on GitHub and a 98% increase in the number of projects overall — and many of those contributions came from places like India, Germany, Japan, and Singapore...

Notable growth is occurring in India, which is expected to have the world's largest developer population on GitHub by 2028, as well as across Africa and Latin America... [W]e have seen greater growth outside the United States every year since 2013 — and that trend has sped up over the past few years.
Last year they'd projected India would have the most developers on GitHub #1 by 2027, but now believe it will happen a year later. This year's top 10?

1. United States
2. India
3. China
4. Brazil
5. United Kingdom
6. Russia
7. Germany
8. Indonesia
9. Japan
10. Canada

Interestingly, the UK's population ranks #21 among countries of the world, while Germany ranks #19, and Canada ranks #36.)

GitHub's announcement argues the rise of non-English, high-population regions "is notable given that it is happening at the same time as the proliferation of generative AI tools, which are increasingly enabling developers to engage with code in their natural language." And they offer one more data point: GitHub's For Good First Issue is a curated list of Digital Public Goods that need contributors, connecting those projects with people who want to address a societal challenge and promote sustainable development...

Significantly, 34% of contributors to the top 10 For Good Issue projects... made their first contribution after signing up for GitHub Copilot.
There's now 518 million projects on GitHub — with a year-over-year growth of 25%...

"AI-driven 0-day detection is here," argues a new blog post from ZeroPath, makers of a GitHub app that "detects, verifies, and issues pull requests for security vulnerabilities in your code."

They write that AI-assisted security research "has been quietly advancing" since early 2023, when researchers at the DARPA and ARPA-H's Artificial Intelligence Cyber Challenge demonstrated the first practical applications of LLM-powered vulnerability detection — with new advances continuing. "Since July 2024, ZeroPath's tool has uncovered critical zero-day vulnerabilities — including remote code execution, authentication bypasses, and insecure direct object references — in popular AI platforms and open-source projects." And they ultimately identified security flaws in projects owned by Netflix, Salesforce, and Hulu by "taking a novel approach combining deep program analysis with adversarial AI agents for validation. Our methodology has uncovered numerous critical vulnerabilities in production systems, including several that traditional Static Application Security Testing tools were ill-equipped to find..." TL;DR — most of these bugs are simple and could have been found with a code review from a security researcher or, in some cases, scanners. The historical issue, however, with automating the discovery of these bugs is that traditional SAST tools rely on pattern matching and predefined rules, and miss complex vulnerabilities that do not fit known patterns (i.e. business logic problems, broken authentication flaws, or non-traditional sinks such as from dependencies). They also generate a high rate of false positives.

The beauty of LLMs is that they can reduce ambiguity in most of the situations that caused scanners to be either unusable or produce few findings when mass-scanning open source repositories... To do this well, you need to combine deep program analysis with an adversarial agents that test the plausibility of vulnerabilties at each step. The solution ends up mirroring the traditional phases of a pentest — recon, analysis, exploitation (and remediation which is not mentioned in this post)...

AI-driven vulnerability detection is moving fast... What's intriguing is that many of these vulnerabilities are pretty straightforward — they could've been spotted with a solid code review or standard scanning tools. But conventional methods often miss them because they don't fit neatly into known patterns. That's where AI comes in, helping us catch issues that might slip through the cracks.
"Many vulnerabilities remain undisclosed due to ongoing remediation efforts or pending responsible disclosure processes," according to the blog post, which includes a pie chart showing the biggest categories of vulnerabilities found:

• 53%: Authorization flaws, including roken access control in API endpoints and unauthorized Redis access and configuration exposure. ("Impact: Unauthorized access, data leakage, and resource manipulation across tenant boundaries.")

• 26%: File operation issues, including directory traversal in configuration loading and unsafe file handling in upload features. ("Impact: Unauthorized file access, sensitive data exposure, and potential system compromise.")

• 16%: Code execution vulnerabilities, including command injection in file processing and unsanitized input in system commands. ("Impact: Remote code execution, system command execution, and potential full system compromise.")

The company's CIO/cofounder was "former Red Team at Tesla," according to the startup's profile at YCombinator, and earned over $100,000 as a bug-bounty hunter. (And another co-founded is a former Google security engineer.)

Thanks to Slashdot reader Mirnotoriety for sharing the article.