PHP[TEK] 2024: Pioneering the Future of Web Development in Chicago
Tags: php, security, cybersecurity, chicago
Published: 2024-05-14 12:51:24

Chicago might best be known internationally for its iconic skyscrapers and a certain movie about [two brothers who played the blues](https://www.chicagotribune.com/2024/03/08/44-things-this-chicagoan-didnt-know-about-the-the-blues-brothers/?ref=blog.gitguardian.com). It is also home to a lot of technical firsts and advancements; the [zipper, the dishwasher, and the Ferris wheel](https://www.chicagotribune.com/2014/01/14/chicago-innovations-that-changed-the-world/?ref=blog.gitguardian.com) all premiered in Chicago. That spirit of innovation lives on today as the city hosted a conference to advance the state of the art for building web applications, PHP[TEK] 2024.

PHP[TEK] is the longest-running PHP-focused conference in the US. This year, around 400 participants came from all over the world to talk about open source, frameworks, and how we can build more securely and incur less technical debt. With over 40 sessions, 4 different workshops, and [an unconference](https://en.wikipedia.org/wiki/Unconference?ref=blog.gitguardian.com), a lot of information was shared, and many conversations were had.

Here are just a few highlights from this year's PHP[TEK].

Embracing Change with Humanity at the Core
------------------------------------------

Starting the whole event on a positive note, April Wensel, founder of Compassionate Coding, gave the keynote address, "How to Embrace Change with Curiosity, Creativity, and Compassion." This really set the tone for PHPTEK by addressing the human element in technology. She challenged the audience to consider soft skills as equally vital as hard skills, reminding everyone that "you are a human, working with humans, to make things for humans."

Developers have many current fears about AI potentially rendering their skills obsolete, threatening their identity within the software industry. If we instead embrace what positive changes AI can bring, freeing us from a lot of tedious work and freeing us up to do uniquely human things like being creative, we are going to have a much better experience and less burnout. 

She asked us all to think about our code values along the way. These are our anchor points that can guide us through any changes and help us stay true to ourselves. She encourages us to think about three key strategies for dealing with change:

-   Compassion: Recognize and respond to personal and collective challenges in the workplace in a kind way that assumes good intent.
-   Curiosity: Maintain an inquisitive attitude towards one's own thoughts and the changing dynamics within tech culture.
-   Creativity: Embrace creativity as a mechanism for coping and adapting to change. This involves exploring new ideas and maintaining an openness to unexpected opportunities.

[![](https://blog.gitguardian.com/content/images/2024/04/b820f15c89ac635f2cf6de212b45ea12-2.png)](https://www.linkedin.com/posts/benfausch_phptek-namecom-activity-7188551599202398208--Roh?ref=blog.gitguardian.com)

Learning to manage change with @aprilwensel from @compassionatecoding

The best code is the code you delete
------------------------------------

In the session from [Andy Snell, lead developer at WickedByte](https://www.linkedin.com/in/andysnell/?ref=blog.gitguardian.com), "Zombie Hunt: Find and Safely Remove Undead Code," he walked us through some of the security challenges associated with leaving old and unused code in our projects. Andy described "zombie code" as any executable code that cannot be reliably identified as useful or necessary, including code that may be outdated, no longer in use, or potentially harmful if left within the system. However, removing this potentially dangerous code is fraught with perils, such as accidentally bringing down the whole system because you didn't know the code was still in use and only occasionally called dynamically. 

He introduced the concept of a "Code Tombstone," a production-safe mechanism that helps identify zombie code by triggering alerts when such code is executed. You first identify code you do not believe is ever invoked and then set a very simple function to create a marker file if it is ever called. If, after a certain amount of time, the marker is never triggered, you can assume it is safe to remove. This proactive approach allows developers to gradually phase out unnecessary or risky code segments without disrupting the operational integrity of their systems. He did warn you need to wait "long enough, but not too long" and that time intervals will be highly situational and require some judgment. 

Identifying which dependencies are never invoked is a good place to start, as dependencies can introduce all sorts of vulnerabilities. He suggested that for PHP projects, developers use [composer-unused](https://github.com/composer-unused/composer-unused?ref=blog.gitguardian.com), a command line utility that can quickly scan code and determine if a dependency is ever utilized. 

[![](https://blog.gitguardian.com/content/images/2024/04/99d159be9ad67a4a02e4f3ea76c42833-1.png)](https://www.linkedin.com/posts/dwaynemcdaniel_phptek-activity-7188555064431579137-qRo?ref=blog.gitguardian.com)

Zombie Hunt: Find and Safely Remove Undead Code from Andy Snell 

Composer and Supply Chain Security
----------------------------------

PHP[TEK] was lucky this year to have [Nils Adermann, the creator of Composer](https://www.linkedin.com/in/nilsadermann/?ref=blog.gitguardian.com), as a speaker. In his talk "Composer Guide to Supply Chain Security," he highlighted the vulnerabilities and risks associated with software dependencies. Adermann discussed the increasing prevalence of supply chain attacks and walked us through some major breaches like [Heartbleed](https://heartbleed.com/?ref=blog.gitguardian.com), SolarWinds, Log4Shell, and the very recent [xz util backdoor](https://blog.gitguardian.com/the-backdoor-that-almost-compromised-ssh-security/). He stressed the importance of understanding and securing the software supply chain, from direct code dependencies to the tools and services that support software development.

Nil's talk covered practical measures such as regular updates, vendor audits, and the use of built-in composer commands like `composer audit` to identify and mitigate vulnerabilities in project dependencies. He also pointed out the value of maintaining an accurate and comprehensive record of the software supply chain via an up-to-date [SBOM](https://blog.gitguardian.com/what_is_sbom/). He also encouraged documenting all your processes and CI/CD steps to make sure you are securing your whole build and delivery system. 

He concluded by calling for using secured versions of dependencies maintained as a private package repository. He walked us through the steps of running a vulnerability check using commonly available tools and what it takes to maintain your own versions of these code bases. He also made it clear that there are [commercial vendors](https://www.chainguard.dev/case-studies/gitguardian-mastering-secure-code-from-the-ground-up?ref=blog.gitguardian.com) who would be glad to assist you with this if you don't have the bandwidth to manage your own [Packagist](https://packagist.com/about/?ref=blog.gitguardian.com).  

[![Image preview](https://blog.gitguardian.com/content/images/2024/05/890549715a9ede9562c8b24b9bc76b26-35.jpeg)](https://www.linkedin.com/posts/dwaynemcdaniel_php-composer-phptek-activity-7188583556770684930-aPWn?ref=blog.gitguardian.com)

Nils Adermann presenting "Composer Guide to Supply Chain Security"

Understanding data regulation basics can save a lot of headaches 
-----------------------------------------------------------------

[Kaitlyn Concilio, Principal Software Engineer at 8th Light](https://www.linkedin.com/in/kaitlynconcilio/?ref=blog.gitguardian.com), gave us a lot of references in her talk "Data Regulations for Software Developers." She explained we are developing more and more global data protection standards. Regulations like GDPR and HIPAA carry stiff penalties and bring reputational risks, meaning no one will want to do business with companies that violate the rules. She also walked us through newer frameworks, such as the [EU AI Act](https://artificialintelligenceact.eu/?ref=blog.gitguardian.com), which sets stringent rules around the use of AI, particularly in identifying and profiling individuals.

Developers must not only be aware of these regulations but actively engage in practices that ensure compliance. She warned that being ignorant of the law is never an excuse. This includes understanding the legal terminology and the specific requirements of the laws applicable to their projects, especially when handling sensitive user data. When in doubt, it is far better to ask your legal team before collecting or using data in a new way. Also, be wary of anyone claiming, "We have always done it this way." That could mean you have years of violations that might come to light. 

One positive note Kaitlyn pointed out during her conclusion was that we don't have to adhere to every standard simultaneously. If we just stay focused on adhering to the ones applicable to our situation, and thanks to regulatory overlap, we will be in an overall good position. Kaitlyn encouraged us to all keep aware of the news about regulation changes and to ask questions when asked about working with a new data source, especially if it is customer data.

[![](https://blog.gitguardian.com/content/images/2024/04/09869729b02b78041be3c1cc7724a07a-1.png)](https://www.linkedin.com/posts/dwaynemcdaniel_phptek-activity-7188916370074484736-1iOD?ref=blog.gitguardian.com)

Data regulations for software developers by Kaitlyn Concilio

Mental Health: A Priority for Developers
----------------------------------------

It is easy to overlook the human costs of relentless innovation. [Sarah Savage, President at Carved Path Consulting](https://www.linkedin.com/in/sarahsavage020/?ref=blog.gitguardian.com), brought to light the mental toll our rapid pace of change can take on developers in her session, "5 Things About Mental Health Every Developer Should Know." She discussed the prevalence of mental health issues within the tech community and the various support systems and resources we can turn to. 

She reminded us that everyone has a mental health status, just like we have a physical health status. Mental health issues can affect anyone, and we need to remove the stigma of addressing our health. She explained there is a continuum of care for mental health, not just therapy or mental hospitalization. Start with your family physician and ask for referrals to programs like Meet You Where You Are on Your Journey, taking advantage of residential programs if that is going to help you heal.  

She also introduced the audience to the idea of mental first aid.  This is knowing how to approach someone who is having a crisis and assist them to get the help they need in a dignified way. Sarah recommended the website [Mental Health First Aid](https://www.mentalhealthfirstaid.org/?ref=blog.gitguardian.com) as a place to learn more about this subject and to register for a training course in your area.

[![](https://blog.gitguardian.com/content/images/2024/04/fb7e2b6cb6e63eabc5521efa96a1fab7-1.png)](https://www.linkedin.com/posts/dwaynemcdaniel_phptek-activity-7189286240695771136-PlsX?ref=blog.gitguardian.com)

"5 things about mental health every developer should know" an unconference session at #phptek from Sarah Savage

Navigating change while developing safely
-----------------------------------------

Throughout PHP[TEK] 2024 one message came through many of the sessions: we need to embrace change, whether technological or personal. It is not just beneficial but necessary for growth and sustainability. Some of this change means being more aware of what we are putting in our code and what security repercussions that can have.

For example, adding plaintext secrets to code is a surefire way to weaken your security posture. We should [use the right tools to find and eliminate these hardcoded credentials](https://www.gitguardian.com/monitor-internal-repositories-for-secrets?ref=blog.gitguardian.com). But there are also things we can add to our code to help us keep adversaries at bay, such as [Honeytokens](https://www.gitguardian.com/honeytoken?ref=blog.gitguardian.com). Your author got to speak about both these subjects at the event. 

[PHP still makes up over 76% of the code on the internet](https://w3techs.com/technologies/overview/programming_language?ref=blog.gitguardian.com). Securing PHP applications means securing our global communications platform. The community is large and has a rich history. It is also a very welcoming group and I would encourage everyone to start making plans to attend next year's PHP[TEK].